Full Build
The version you would put a paying customer in front of.
2 weeks from kickoff
elapsed
50% now to book the start, 50% on completion. Priced and charged in US dollars.
Where your customers use it
The price covers one. Each one after that adds $10,000 USD.
Total
$10,000 USD
Web
2 weeks from kickoff
What you pay, and when
- Due today50% — books the start
- $5,000 USD
- On completion50% — at handover, nothing withheld
- $5,000 USD
- Total
- $10,000 USD
Secure checkout by Stripe. Card details never reach this site.
Who it is for
It has to work when strangers use it, and you want that to be somebody’s job.
Not for you if
You are still deciding what it is. Scope it as an MVP first and grow it.
What you get
In detail
Auth, and the parts that go wrong
Sessions that survive a refresh and expire when they should, the routes that must never be public, and the check living on the server no matter what the interface is doing — a hidden button is not a permission. Password reset and email verification handled as the attack surface they are, since they are the two flows that let a stranger become a user.
Data that outlives its first schema
Migrations that survive contact with a database nobody planned for, run in order and reversible, with the ones that need care flagged as needing it. Including the failure this very site shipped: an index built on a column that did not exist yet, which passed every check locally and killed a feature in production and nowhere else. The point of naming it is that the class of thing is normal, and the handling for it is what you are buying.
Taking money, including when it goes sideways
Payments where the confirmation comes from the provider rather than the browser, because a customer closing the tab must not decide whether they paid. Webhooks that assume they will arrive twice, out of order, or late, and are safe in all three cases. The states you actually have to handle — pending, failed, refunded, disputed — rather than the happy path and a shrug.
Knowing before your customers tell you
Logging you will actually read rather than a firehose nobody opens, errors carrying a reference the person on the phone can quote back to you, and something honest on the page when it breaks instead of a blank screen. Alerts on the handful of things that mean money is not moving, because everything alerting is the same as nothing alerting.
Two rounds, and a handover with a person attached
Two rounds of changes after you have used it, and a call at the end where you are walked through what was built and why it is shaped the way it is. Written notes for the things that will eventually happen — a dependency to update, a key to rotate, a provider to swap — so the documentation has a person attached to it rather than being a file nobody has read.
Something a stranger can use unsupervised
The difference between this and the MVP is not more screens. It is that nobody has to stand next to the user: the failure paths are handled, the money is handled, the edges a real person finds within a week are handled, and you hear about problems from your monitoring rather than from a customer who has already given up.
The boundary
What the price covers, in numbers
A fixed price with an unbounded scope is not a price. These are generous enough that almost every honest brief fits — they exist so the one that does not is recognised now rather than in week two.
- Screens
- Distinct views a user can reach, across all roles. Empty, loading and error states are included in every one rather than counted separately.
- Up to 18
- User roles
- For example customer, staff and admin, with genuinely different permissions and different views.
- Up to 3
- Data models
- Tables in the schema, including the ones auth and billing bring with them.
- Up to 20
- Third-party integrations
- Auth is included and does not count. Pick the two that matter — payments, email, a CRM, a calendar, one API. A third is quotable, not refused.
- 2 of your choosing
- Rounds of changes
- Within 30 days of handover. Anything that does not match the scope document is a fix, not a round.
- 2
- Data migration
- A clean export from one existing system. Beyond that, or from several systems at once, is a separate job.
- Up to one source, 50,000 records
- Expected load
- Sensible indexes, pagination and rate limits. Architecture for a scale you have not reached yet is a cost with no return, and it is not included.
- Built for thousands of users, not millions
The week
What actually happens, in order
- Before week 1Brief, access and the scope document. One page, approved by you, naming what is being built and what is explicitly not. Nothing starts before that.
- Week 1, days 1–2Data model, auth, roles and permissions. The parts everything else depends on, done first because they are the expensive things to change later.
- Week 1, days 3–5The main flows. Staging URL live and updated continuously — you are reviewing all week, not at the end.
- Week 2, days 1–2The two integrations you picked. Payments, webhooks and the states the network forces on you.
- Week 2, days 3–4Error handling, rate limits, the security traps that apply, logging you will actually read.
- Week 2, day 5Production on your domain, documentation, handover call. Balance falls due; the repo transfers.
- Within 30 daysYour two rounds of changes.
Finished means
When it counts as delivered
- — Every flow in the scope document works in production on your domain, for every role
- — Auth, permissions and the two chosen integrations are working, including their failure paths
- — Errors are logged with a reference you can trace, and the app says something honest when it breaks
- — The repo is transferred and deploys from your account; a handover call has happened
- — Documentation covers the architecture, the deployment and the decisions behind both
Never at this price
Out of scope, however it is asked for
- — Brand, logo or visual identity design
- — Copywriting beyond interface labels
- — Ongoing hosting, maintenance, monitoring, on-call or support after the change rounds
- — Compliance certification: SOC 2, HIPAA, PCI Level 1, ISO 27001 — the build follows sensible practice, but certification is an audit, not a feature
- — Legal documents — terms, privacy policy, contracts
- — Integrations with on-premise or bespoke enterprise systems
- — Native mobile apps unless the platform toggle is on, which prices them
- — Machine learning models trained on your data
- — Uptime guarantees or a support SLA
- — Third-party licence, infrastructure or API costs, which stay yours
If it changes
How a change is handled
The scope document is the agreement
One page, approved by you before anything is built, naming what is in and what is not. If something is not on it, it is not in the build — not as a refusal, but so that both of us know what was agreed when we are three days in and busy.
A brief bigger than the tier is caught at the scope stage
That is what the stage is for. You will hear it before you have waited a week, not after. Then it is your choice: cut it back to fit, move up a tier and pay the difference, or take a refund. Nothing has been lost but a conversation.
Changes during the build are quoted, not absorbed
Wanting something different once you see it is normal and welcome. It is also new work: it gets an estimate and a date before it starts, and it never quietly displaces something already agreed. A change that fits inside the scope in exchange for something coming out is free — that is a trade, not an addition.
A fix is not a change
If it does not do what the scope document says, that is a defect and it gets fixed at no cost and without spending a round. Rounds are for things you have changed your mind about.
The limits above are the boundary of the price
Not a refusal to do more. Beyond them is simply a bigger job, quoted as one — which is fairer than pretending a five-day week can absorb a five-week brief.
How it runs
01 You pay half and take a slot
Prices are on this page, not behind a call. Half up front reserves a build week — only a couple run at a time, which is why the dates are real and why the slot is what you are actually buying.
02 You send the brief
A few questions, plus anything you already have: designs, reference URLs, a spreadsheet of how it works today, access to whatever it has to connect to. Ten minutes, and it is the ten minutes that decides how this goes.
03 The scope is agreed in writing
One page: what is being built, what is explicitly not, and the date. You approve it before anything is written.
04 You see it early
A working URL well before the end, not a reveal at the finish. Changes are cheap while it is being built and expensive afterwards, which is the entire reason you see it early.
05 Handover
The balance falls due, the repo transfers to you and it goes live under your own account. Then your round or rounds of changes.
What to bring
A clear idea of which part is being built
Not the whole roadmap — the piece. Knowing that this build is the booking flow and not the billing is worth more than any technical vocabulary.
The detail behind it
The rules that live in your head: who is allowed to do what, what happens on the awkward Tuesday, the customer who always asks for the exception. That context is the difference between something that works and something that demos.
Coding knowledge, if you have it
Helpful, never required. It makes the review conversations quicker and it means the handover documentation lands sooner. Plenty of people buy a build having never opened an editor, and it goes fine.
One person who decides
Somebody who can answer a question the same day. Most delays on a short build are not technical.
Start a Full Build
Tell us what it has to do and who uses it. If the brief is bigger than this tier we will say so before you pay, not in week two.