Next.js development for Birmingham manufacturers and public bodies

Birmingham has two kinds of buyer and they want opposite things from the same technology.

One is industrial - manufacturers, engineering firms, distributors with catalogues measured in tens of thousands of parts. The other is public or quasi-public - the city council, the combined authority, universities, NHS trusts and the organisations that contract with them. The first group has a data problem. The second has a statutory obligation, and it has an enforcement route attached.

Accessibility here is a duty, not a guideline

For a public sector body in the UK, accessibility is regulated rather than recommended, and the published accessibility statement is the part that makes it real.

The statement has to say what on the site does not conform and why. That one requirement converts accessibility from an intention into an audit, because somebody has to have actually tested the thing in order to write an honest statement about it.

For an App Router application the failures are predictable and they are not about colour contrast. Focus is lost when a client-side navigation replaces the page and nothing moves the keyboard. A loading state renders a skeleton that a screen reader announces as nothing at all. A Server Action returns a validation error that is displayed in a styled box with no programmatic relationship to the field it concerns.

All three are fixable and none are visible to a sighted developer with a mouse. That is why they survive into production, and why testing with a keyboard and a screen reader is a line item rather than a hope.

The catalogue lives somewhere else

For the industrial half of Birmingham, the interesting constraint is that the website does not own its own content.

Product data sits in an ERP, sometimes in a product information system, occasionally in a spreadsheet that one person maintains. The site reads from it. That is the correct arrangement, and it makes two things matter - the interface between the two, and what happens when the data is incomplete.

Incompleteness is guaranteed. Any catalogue of that size has products with no image, missing dimensions, a description written in 2011 and a replacement part that points at something discontinued. A design that assumes complete records produces broken cards; a design that expects gaps renders a usefully reduced page instead. Deciding which fields are required to publish at all is a content decision with a technical consequence, and it belongs in week one.

Ten thousand variants is not ten thousand pages

The other recurring Birmingham question is how much of a catalogue should be on the public web.

The instinct is everything, one URL per variant, on the theory that more pages means more chances to rank. What it actually produces is thousands of near-identical pages differing by a number in a table, which is the definition of thin content and is treated as such.

The version that works puts the product family on the page that competes, carries the variants as structured data within it, and spends the real writing on the engineering question somebody actually typed - how to choose, what it is compatible with, what fails and why. Structured data handles the variants; the prose handles the query.

Commercially

Scope fixed in writing before work starts, priced per project. The country-level ground - UK data protection after divergence from the EU, consent, invoicing in pounds - is on the United Kingdom market page.

Invoiced by Codefacture Yazılım A.Ş. in Türkiye, in pounds or euros by bank transfer, with no Turkish VAT because exported services are exempt.