Service 01 of 04
Webdevelopment
Sites and applications built on boring, durable choices — so the thing still runs in four years, and your team can change it without us.
Who this is for
Organisations that should own their own site.
Independent hotels, restaurants, and hospitality businesses that have outgrown their booking platform's built-in site — or whose site belongs to an agency and not to them.
Charities and professional services that need a maintainable site without a permanent developer on staff.
Organisations inheriting an unmaintainable codebase — a WordPress install only the original agency can touch, or a custom build with no documentation.
Any team that wants to be able to update, redeploy, and hand the work to another studio without starting from scratch.
Typical engagements
Marketing sites & editorial
Content-led sites with a model your team can actually edit.
4–7 weeksBooking & commerce flows
Checkout, reservations and the states around them designed first.
6–12 weeksInternal tools & dashboards
The unglamorous software a team lives in all day.
ScopedTakeover of an existing build
Inheriting someone else's codebase without a full rebuild.
Day rateFour phases,
fixed at the start.
A fixed price and a fixed shape, agreed before we write any code.
Scope
A week of reading what exists — analytics, support tickets, the CMS your editors actually avoid. Ends in a written scope with dates and a fixed price.
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.
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.
Handover
Repository, hosting, domain and analytics transferred to your accounts. A recorded training session, and a written runbook for the three things most likely to break.
The stack
Boring choices on purpose.
We use tools with a long track record, large communities, and no lock-in. Nothing that requires a licence from us to keep running.
Next.js or Astro
Static-first, fast on a mid-range Android on 4G. We pick the simpler one that fits the content model, not the one with the most features.
Sanity or markdown files
Sanity for structured editorial: fields named after things your editors understand. Markdown when the team is comfortable in a code editor.
Postgres or SQLite
When the project needs a database. Often it does not, and we will say so.
Vercel or Render
One-click deploys. Your account, your card, your access. We never hold credentials.
Written into every contract
The handover is the deliverable.
Work
40-room island hotel group
Marketing site and booking flow. Sanity CMS with fields named after the things reception staff actually talk about. All credentials transferred at week nine; editor training completed in one 90-minute recorded session. The client's developer can deploy without us.
Charity migrating from unmaintainable WordPress
Astro static site. Content model built around the two non-technical staff who update it. No plugins, no update cycle, no security surface. Hosting cost reduced by roughly £180 per month.
Restaurant group — internal bookings dashboard
Next.js tool for a four-venue group. Handed over with a deploy runbook and a written list of the five things most likely to need changing in the first year, with instructions for each.
What you get, every time
Content model your editors can use
Fields named after things, not editor layouts.
Performance budget, held
Agreed in the scope and tested on a mid-range Android.
Accessibility as a build step
Keyboard paths and contrast checked per page type, not at the end.
A runbook, not a slide deck
Deploys, rollbacks, and who to call.
A written reply first — no discovery call before we have read something.