Skip to content

Next.js in Glasgow

Next.js development for Glasgow public services and housing

A Next.js development company for Glasgow councils and housing associations. Services used on old phones and borrowed devices, where a form has to work without JavaScript.

Working day overlap
About five hours, three hours behind Ankara, the same as the rest of the UK
Who buys here
Local authorities, housing associations, social enterprises, universities and the engineering firms along the Clyde
What that changes
The audience is the general public rather than a customer segment, so the device and connection assumptions have to be the worst ones rather than the average
Local specifics
A tenant or claimant service is often used on a borrowed or ageing device, which makes a form that works without JavaScript a requirement rather than a purist position

Glasgow's public services are used by people who did not choose to be users.

A tenant reporting a repair, somebody applying for support, a parent filling in a school form - none of them picked the service, and none of them can go elsewhere if it is slow or confusing. That changes the engineering baseline in a way that commercial projects rarely have to think about: the assumptions have to be the worst plausible ones rather than the average ones.

The form has to work when nothing else does

This is the Glasgow requirement that most modern web development has quietly stopped meeting.

A service form built as a client-side component needs JavaScript to download, parse and execute before it will accept input. On a current phone that is imperceptible. On a five-year-old Android handset on a weak connection, or on a library computer with an aggressive content filter, or on a device where something failed to load for no reason anybody will ever diagnose, it is a form that does nothing when you press the button.

Built correctly, the same form posts to the server like any form has since 1995. A Server Action attached to a plain form element submits without JavaScript, the server validates and responds, and the page renders. JavaScript then makes it nicer - validation as you type, no full page reload, a disabled button while it submits - without being load-bearing.

That is the difference between a service that degrades and a service that breaks, and for this audience it is not a philosophical position. Server Actions are the mechanism, and the discipline is to write the form so the enhancement is optional.

Measure on the device people actually have

The second half of the same argument is the JavaScript budget.

Every library added to a page is paid for by the slowest device in the audience, and for a public service the slowest device is not a rounding error - it is a significant share of the people who need the service most. A bundle that costs forty milliseconds on a developer's laptop can cost two seconds on a handset that is three generations old.

So interactivity gets justified individually rather than assumed. A date picker, an address lookup, a progress indicator on a long upload - these may be worth their weight. A table of repair statuses rendered by React in the browser is not, because the server can send the same table as markup for nothing.

When a Glasgow build is the wrong answer

Worth saying plainly, because it is often true.

If what an organisation needs is some published information and a few forms, a properly configured content management system with accessible templates will serve its users better than a bespoke application with no maintenance budget behind it. Custom development earns its place when a service has state somebody returns to - a repair with a status, a rent account, an application in progress - because that is the point at which off-the-shelf tools stop helping and start resisting.

We would rather say that at the start than build something that is abandoned in three years. When not to use Next.js is the longer version of the same argument.

Commercially

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

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

The regulatory and commercial ground for this city is on the United Kingdom market page.

Frequently asked questions

Does a Next.js form really work with JavaScript disabled?
A Server Action submitted from a plain form element does, and that is the point of building it that way. The browser posts the form, the server processes it and renders the response, exactly as the web worked before client-side frameworks. JavaScript then improves it - inline validation, no full reload - without being the thing that makes it function. For a service someone has to use rather than chooses to use, that distinction is the difference between degraded and broken.
Our users are on old Android phones. What does that change?
Mostly the JavaScript budget, and more than people expect. On a five-year-old handset, parsing and executing a large bundle costs seconds rather than milliseconds, and those seconds land before anything is usable. The practical consequence is that interactivity has to be justified individually - a date picker may earn its weight, a server-rendered summary table does not - and that the site should be measured on a throttled device rather than on the machine it was built on.
We are a Glasgow housing association. Is a custom build even the right answer?
Often it is not, and it is worth saying so. If the requirement is a handful of forms and some published information, a well-configured content system with accessible templates will serve tenants better than a bespoke application nobody has budget to maintain. Where a custom build earns its place is when a service has real state - a repair request with a status, a rent account, a case somebody returns to - because that is where off-the-shelf tools start fighting you.
Who is responsible for accessibility conformance?
The organisation is, which is exactly why it has to be built in rather than reviewed at the end. For a public body the accessibility statement has to be accurate about what fails, so testing with a keyboard and a screen reader is part of the work rather than a sign-off. We write what we tested and what we found, because a statement nobody can stand behind is worse than an honest list of known problems.
Call us+1 848 272 7583WhatsApp+90 850 308 5436Emailinfo@codefacture.comContact page