Web application development

Applications, not templates

There is a real difference between a page that presents information and an application that people work inside. The second has state, permissions, data that changes while you are looking at it, and users who will be in it for hours. Building one on foundations meant for the other is the most common and most expensive mistake in web work.

We build both, but we build them as what they are. A product site is engineered for speed and for being found. An application is engineered for the fact that someone will have forty tabs of it open and expect every one to be correct.

React, Next.js and TypeScript

Next.js renders on the server, which matters for two reasons that are usually discussed separately and are really the same reason. A page that arrives as finished HTML is readable by a search crawler without executing JavaScript, and it is visible to a person on a slow connection seconds earlier. Client-only applications fail at both.

TypeScript across the whole stack means the shape of the data is checked at the boundary between the server and the interface, not discovered at runtime by a user. Combined with a typed API — usually Python and FastAPI — a change to a field name breaks the build rather than the product.

Speed as a feature

Performance is not a polish item added at the end. It is decided by architecture: what renders on the server, how much JavaScript is shipped, whether images are sized for the device asking for them, and how much of the page has to wait for a network round trip before anything is legible.

Those decisions are made at the start because they are difficult to reverse later, and they are measured on real devices and real connections rather than on a developer machine with fibre.

Accessible and findable

Semantic markup, keyboard navigation, honest contrast ratios and respect for reduced-motion settings are not extras. They are what makes a site usable by everyone who arrives at it, and the same structure that makes a page comprehensible to a screen reader is what makes it comprehensible to a search crawler.

Technical SEO follows from the same work: server-rendered content, correct canonicals, structured data, a real sitemap, and metadata written for the query the page is meant to answer rather than stuffed with terms.

Built to be handed over

You get the code, the infrastructure and the ability to run it without us. We would rather keep working with you because the work is good than because leaving is difficult.

If you have a web product in mind, or one that has outgrown what it was built on, describe it to us and we will tell you what it would take.