MVP

What you get

1. 01

   Scope agreed in writing first

   One page: what is being built, what is explicitly not, and the date. You approve it before anything is written. If the brief describes a bigger job than the tier, you hear that here — not halfway through.

2. 02

   One flow, done properly

   Carried end to end, including the states nobody demos: empty, loading, failed, and the one where somebody did something unexpected.

3. 03

   Yours on completion

   You get read access from the first commit and a running URL well before the end, so nothing is hidden while it is being built. Ownership of the repo transfers and it goes live on your domain when the balance clears — that is what the second half pays for.

4. 04

   A round of changes after you have used it

   After, not before. Feedback from using a thing is worth more than feedback from imagining it.

5. 05

   Something you can actually launch with

   Not a prototype with the interesting parts stubbed. Real accounts, real data, real payments if that is the flow — the thing a first customer can use without being told which buttons not to press.

How the build runs

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

1. Before day 1You send the brief and any access. The scope document comes back for your approval — one page, what is being built and what is not. Nothing starts until you approve it.
2. Day 1Data model and the skeleton of the app. Repo created, deploy pipeline running, staging URL live and shared with you.
3. Days 2–3The primary flow, end to end. This is where most of the work is and where you will see the most change day to day.
4. Day 4The states nobody demos: empty, loading, failed, the awkward input. Auth wired properly. Your review starts here, not at the end.
5. Day 5Your domain, production deploy, documentation, handover. Balance falls due; the repo transfers.
6. Within 14 daysYour one round of changes, once you have used it in anger.

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 8Distinct views a user can reach. A list and its detail view are two. Empty, loading and error states are not counted — they are included in every screen.
• User roles1, plus an admin viewOne kind of signed-in user. A second role with genuinely different permissions is a Full Build.
• Data modelsUp to 8Tables in the schema. Enough for a real product; a brief that needs twenty is describing something larger.
• Third-party integrations1Auth is included and does not count. One further integration — payments, email, a calendar, one API — is in scope.
• Rounds of changes1After you have used it, within 14 days of handover. Fixes to things that do not match the scope document are not a round; they are just fixes.
• Data migrationNot includedStarting with an empty database. Bringing across existing records is a separate, quotable job.

When it counts as delivered

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

• ✓ The primary flow works end to end on your domain, in production, with real accounts
• ✓ Every screen in the scope document exists and handles empty, loading and error states
• ✓ The repo is transferred to you and the deploy runs from your own account
• ✓ Documentation covers how it works, how to run it locally and how to change it

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 — the build uses a clean default or your existing brand
• — Copywriting beyond interface labels
• — Migrating existing data from another system
• — Ongoing hosting, maintenance, monitoring or support after the change round
• — Compliance certification: SOC 2, HIPAA, PCI Level 1, ISO 27001
• — 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
• — Load testing or capacity guarantees

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.