Full Build

What you get

1. 01

   Auth, and the parts that go wrong

   Sessions, the routes that must never be public, and why the check belongs on the server no matter what the interface does.

2. 02

   Data that outlives its first schema

   Migrations that survive contact with a database nobody planned for. Including the failure this very site shipped: an index built on a column that did not exist yet, which killed a feature in production and nowhere else.

3. 03

   Taking money

   Payments, what a webhook actually guarantees, and the states you have to handle because the network does not care about your happy path.

4. 04

   Knowing before your users tell you

   Logging you will actually read, errors with a reference you can trace, and something honest on the page when it breaks.

5. 05

   Two rounds, and a handover

   A call at the end where you are walked through it, so the documentation has a person attached to it.

6. 06

   Something a stranger can use unsupervised

   The difference between this and the MVP is not more screens. It is that nobody has to be standing next to the user: the failure paths are handled, the money is handled, and you find out about problems before your customers tell you.

How the build runs

2 weeks from kickoff. You review throughout rather than at the end — a staging URL is live from the first day and updated continuously.

1. 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.
2. 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.
3. Week 1, days 3–5The main flows. Staging URL live and updated continuously — you are reviewing all week, not at the end.
4. Week 2, days 1–2The two integrations you picked. Payments, webhooks and the states the network forces on you.
5. Week 2, days 3–4Error handling, rate limits, the security traps that apply, logging you will actually read.
6. Week 2, day 5Production on your domain, documentation, handover call. Balance falls due; the repo transfers.
7. Within 30 daysYour two rounds of changes.

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 at the scope stage rather than in week two.

• ScreensUp to 18Distinct views a user can reach, across all roles. Empty, loading and error states are included in every one rather than counted separately.
• User rolesUp to 3For example customer, staff and admin, with genuinely different permissions and different views.
• Data modelsUp to 20Tables in the schema, including the ones auth and billing bring with them.
• Third-party integrations2 of your choosingAuth 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.
• Rounds of changes2Within 30 days of handover. Anything that does not match the scope document is a fix, not a round.
• Data migrationUp to one source, 50,000 recordsA clean export from one existing system. Beyond that, or from several systems at once, is a separate job.
• Expected loadBuilt for thousands of users, not millionsSensible 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.

When it counts as delivered

Written down so “done” cannot drift. Every one of these is true before the balance is due.

• ✓ 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

Not included

Said plainly rather than left to be discovered. None of it is refused — it is simply a different job, quoted as one.

• — 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 turns out to be bigger

Every fixed-price build meets this eventually. Handled late it is an argument; written down in advance it is a conversation.

1. 01

   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.

2. 02

   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.

3. 03

   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.

4. 04

   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.

5. 05

   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.

What we need from you

The date is measured from kickoff, and kickoff is when these are in. A week waiting on an answer is a week off the calendar.

• 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.