There is a point in most projects where design stops being the hard part. The pages look right, the words are settled, and then somebody asks what happens after a customer presses the button. Where does the order go. Who gets told. What does the owner see on Monday morning. How does a price get changed without ringing anyone.
That is web development, and it is the half of the work that decides whether a site earns anything. A brochure can be beautiful and still leave every transaction happening in an inbox, a spreadsheet and a phone call.
We build the whole thing: the interface and the machinery under it, in one codebase, owned by you. No page builder to outgrow, no plugin stack that breaks when one of thirty vendors stops updating.
What gets built here
Every engagement is different, but the work falls into a short list of shapes:
- Ordering and checkout — carts, pickup and delivery windows, deposits, order records a customer can look up.
- Owner tooling — the admin screens a business is actually run from, rather than a database somebody has to be trained on.
- Accounts and portals — logins, saved details, order history, documents, anything a customer should not have to email to ask for.
- Bookings and scheduling — availability that reflects real capacity, notice periods and lead times, confirmations that send themselves.
- Integrations — payments, email and SMS, calendars, accounting, whatever the business already runs on.
- Content the owner edits — so adding a page, a product or a price does not require a developer and therefore stops happening.
Built to be handed over
A custom build is only an asset if you can leave. Every project ships with the source in a repository you own, a hosting arrangement in your name, and documentation written for the person who has to run it — not for the developer who wrote it.
That is a deliberate commercial position. A studio that keeps the keys has a client who cannot go anywhere; we would rather have one who stays because leaving was easy and they did not want to.
Fast because it was measured, not because it was promised
Performance is a number, so it gets treated as one. Pages are measured on a production build rather than a developer's laptop, and a slow one gets profiled rather than guessed at.
On the Sweet Squares rebuild the homepage scroll was reported as clunky. Profiling found two 3D scenes still rendering at sixty frames a second while the reader was down in the footer — nothing to do with the animation work itself. Pausing them off screen took the median frame from 50ms to 16.7ms. That is the kind of finding you only get by measuring.
Search, accessibility and the things that are cheaper to do first
Technical SEO and accessibility are part of the build rather than a phase at the end, because both are dramatically cheaper before launch than after. Every build ships with a real URL structure, canonicals, structured data, an accurate sitemap, and redirects for anything that moved.
Accessibility is held to WCAG 2.2 AA and checked with automated tooling and a keyboard, not asserted in a paragraph. It is also, in practice, the same work as making a site usable on a bad phone on bad signal.
Work that shows it
Sweet Squares
The box you can actually build, instead of the one you had to describe.
A family dessert business whose site could take an order by email but could not record one, price one accurately, or say what was in the box.
Local food · Dessert bakeryRebuild in progress · current site still live
Nostos Beach House
From a guest manual to a coastal experience worth booking.
The old site was a ten-page guide for people who had already booked. There was no property story, no photography worth the coastline, and no way to reserve anything. We built the experience that was missing — and kept the guide the owners had written.
Hospitality · Vacation rentalRebuilt and live
Common questions
What do you build with?
Next.js and TypeScript, with PostgreSQL where there is data to keep. It is a deliberately unexotic stack: widely known, long-supported, and staffable by somebody who is not us. The interesting decisions should be in your business logic, not in the framework.
Can you work with the site we already have?
Often, yes. If the existing site is sound and the gap is functional — you need ordering, or a portal, or an admin — that can be built alongside what exists rather than replacing it. The audit says which is cheaper, and it happens before you commit.
Do you do WordPress?
We do not build new sites on it. If you already have one and it is working, we will say so rather than sell you a rebuild. What we will not do is add the fifteenth plugin to a stack that is already the reason the site is slow.
Who owns the code?
You do, from the first commit, in a repository in your name. Hosting is in your account too. There is no arrangement here where leaving costs you the work you paid for.
What happens after launch?
Whatever you want to happen. Some clients take the keys and run it themselves — that is what the handover is for. Others keep us on for changes and monitoring. Neither is a condition of the other.