How we work
Days instead of months, without cutting corners
Projects are rarely slow because the code is hard. They are slow because nobody wrote down what was being built. We fix that first, then build once.
The process
Four stages, in order
01
Day 0 — half a day
Scope
One call, then a written scope document listing every screen, every rule, and everything explicitly out of scope. You approve it before anything is built. This is where the speed comes from: nothing is decided twice.
02
The defined window
Build
One developer owns the build end to end, working from the approved scope. Three days for a website, seven for an internal system. You get a live link from the first day and can watch it take shape rather than waiting for a reveal.
03
One round
Review
You use the real thing with real data and send one consolidated list of changes. We fix everything on it that sits inside the scope. One round, not five — which is why the scope document matters so much.
04
Delivery day
Launch
Deployed to your domain, on your accounts, with the code and data in your name. You get a handover session and written documentation. Thirty days of support follow, whether or not you take a care plan.
Why it holds up
Speed is a process choice
A fixed price only works if the work is genuinely predictable. These are the four things that make it predictable.
Fast is not rushed
The build window is short because the deciding happened first. We are not compressing the engineering, we are removing the waiting: no approval chains, no handoffs between four people, no rebuilding after a change of mind in week three.
The scope is the product
Most agency overruns are scope problems wearing an engineering costume. We spend a disproportionate amount of effort on the scope document so the build is mechanical.
We say no in writing
If something cannot be built well inside the window, we tell you before you pay, and either quote it as a second phase or turn the work down.
Boring technology on purpose
We use well-supported, unfashionable tools. Your system should still run in five years, and any competent developer should be able to pick it up.
What we need from you
The timeline runs both ways
We hold our dates. Holding them depends on a few things from your side. If any of them slip, the date moves and we will tell you the same day.
Client checklist
- One decision-maker who can approve the scope
- Answers inside a working day during the build window
- Content, logos, and copy source material at kick-off
- Access to domains, hosting, and any systems we integrate with
- Real sample data for internal systems, even if it's messy
- Review feedback as one consolidated list, not a drip
- A named person to test it before launch