Web development services
Build systems that outlast
the people who built them
Sites and applications built on boring, durable choices — so the thing still runs in four years, and your team can change it without us.
Built on
- Next.js
- React
- TypeScript
- Astro
- Node.js
- Postgres
- SQLite
- Prisma
- Sanity
- Markdown
- GSAP
- Three.js
- Vercel
- Render
- Cloudflare
- Docker
- GitHub Actions
Development
services we offer
Custom web applications
Software built around your actual workflow rather than a template's idea of it — the unglamorous tools a team lives in all day.
Marketing & editorial sites
Content-led sites with a model your editors can actually use. Fields named after things, not after the layouts they happen to appear in.
MVP builds
The smallest version that proves the idea, scoped so the parts you keep are worth keeping and the parts you throw away were cheap.
Headless & CMS-based sites
Sanity when the editorial is structured, markdown when the team is comfortable in a code editor. Whichever one your people will keep using.
Booking & commerce flows
Checkout, reservations, and the states around them — the failures, the retries, the half-finished baskets — designed before the happy path.
Takeover of an existing build
Inheriting someone else's codebase without a full rebuild — a WordPress install only the original agency can touch, or a custom build with no documentation.
Our core
tech stack
Front-end
- Next.js
- Astro
- React
- TypeScript
- GSAP
- Three.js
Back-end
- Node.js
- Postgres
- SQLite
- Prisma
Content
- Sanity
- Markdown
Hosting
- Vercel
- Render
- Cloudflare
Our project
workflow
Four phases, each ending in something you can hold: a written scope, a content model, a staging URL, and the keys to all of it.
Step #1
Scope
A week of reading what exists — analytics, support tickets, the CMS your editors avoid. Ends in a written scope with dates and a fixed price.
Step #2
Structure
Content model, URL map and page types before any visual design. Most problems are structural, and structure is cheap to change at this stage.
Step #3
Build in the open
A staging URL from week one and a Friday note describing what changed. You never wait for a reveal, and nothing is a surprise at the end.
Step #4
Handover
Repository, hosting, domain and analytics moved to your accounts. A training day, and a runbook for the three things most likely to break.
Tell us what you’re building and we’ll tell you what we’d actually do
- An honest scope
- A stack recommendation
- A rough timeline
- A clear next step
Why clients choose us
You keep the keys
Repository, hosting, domain and analytics live in your accounts from day one. We never hold a credential you cannot revoke.
Boring, durable choices
We pick the simpler tool that fits the content model, not the one with the most features. It is still running in four years.
Scope before code
A week of reading what exists, then a written scope with dates and a fixed price. You approve the shape before anyone opens an editor.
Built in the open
A staging URL from week one and a Friday note describing what changed. Nothing is a surprise at the end because nothing was hidden.
Performance you can check
A budget agreed in the scope and tested on a mid-range Android, not on the laptop that built it.
A runbook, not a slide deck
Deploys, rollbacks, and who to call — written down for the three things most likely to break, and a training day for your team.
FAQ
A written scope, the build itself, and a handover: repository, hosting, domain and analytics moved to your accounts, a training day, and a runbook for the things most likely to break. The handover is part of the work, not an extra.
A marketing or editorial site is usually four to seven weeks. A booking or commerce flow is six to twelve. Takeovers of an existing build are quoted at a day rate because the first job is finding out what is actually there.
Next.js or Astro on the front, Sanity or markdown for content, Postgres or SQLite when a database is genuinely needed, and Vercel or Render for hosting. We pick the simpler option that fits, and we will tell you when you do not need a database at all.
Yes, and often without a full rebuild. A WordPress install only the original agency can touch, or a custom build with no documentation, is a normal starting point. The first week is reading, not writing.
You do, from the first commit. There is no proprietary platform here that you can only leave by rebuilding, and no credential we keep a copy of.
The scope phase ends in a written document with dates and a fixed price. If something changes mid-build we re-scope that piece in writing rather than absorbing it quietly and billing for it later.
They are build steps, not a pass at the end. Keyboard paths and contrast are checked per page type, and the performance budget is agreed in the scope and tested on a mid-range Android.
You can run it yourself — that is the point of the handover. If you would rather we stayed involved, that is a separate arrangement with its own scope, not an assumed retainer.
Not sure where to start?
We’ll help you scope it.
Send over what you have — a brief, a broken site, or a rough idea. You get back an honest read on what the work involves, including whether you need us at all.