From the first commit. Your repository, your hosting, your accounts. There is nothing to migrate off when the engagement ends.

Custom Web Application Development — MVPs, Dashboards, Internal Tools

No phase ends in a status update. Each one ends at a URL you can open.

   phase 1            phase 2            phase 3            phase 4
   ────────           ────────           ────────           ────────

   scope        ────►  data model   ────►  first slice  ────►  the rest
   what it does       schema before      one flow,          remaining flows
   what it won't      any screen         end to end         + operations
       │                  │                  │                  │
       ▼                  ▼                  ▼                  ▼
   written scope      migrations         a URL you          a URL you
   + fixed quote      you can read       can open           can ship

   scope is re-cut between phases, while changing it is still cheap

 1. scope
 what it does, what it won't
     ▼  written scope + fixed quote

 2. data model
 schema before any screen
     ▼  migrations you can read

 3. first slice
 one flow, end to end
     ▼  a URL you can open

 4. the rest
 remaining flows + operations
     ▼  a URL you can ship

 scope is re-cut between phases,
 while changing it is still cheap

That is also what keeps the scope honest: it is hard to argue about progress you can click on, and the re-cut between phases happens while changing direction is still cheap.

What it covers

MVPs The smallest version a real user can pay for or reject. Built to be extended, not thrown away in three months.

Dashboards and internal tools The unglamorous software a team actually runs on. Usually the highest return per week of work in the company.

APIs and data models The schema decides what the product can become, so it gets designed first, on purpose, before any screen exists.

Rescue and rewrite Inherited codebases nobody wants to touch. Starts with a review separating the three real problems from the noise.

Deployment and operations Servers, domains, certificates, backups, logging. Set up once, documented, handed over working.

Integrations Payments, auth, mail, storage, third-party APIs — and the retry logic for when they fail, because they will.

What you end up owning

The repository, yours from the first commit
Infrastructure as code, plus the accounts it runs on
Schema and migrations, readable without a guide
A written map of how it works and where it breaks
Deployment that one person can run without ceremony
The list of what was deliberately left out, and when to revisit it

Terms

MVP

6–10 weeks

Internal tool

2–5 weeks

Engagement

Fixed scope per phase, quoted after the first call

Stack

TypeScript, Next.js, Postgres, Python

Not a fit if

The scope cannot be cut into phases and all of it must land at once
You need a native mobile app — this is web, honestly stated
The deadline is fixed, the scope is fixed, and both are already impossible
Nobody on your side can answer product questions within a day

Questions that come up first

How long does an MVP take?

Six to ten weeks for something real users can use, assuming the scope survives contact with the first phase. Anything quoted at two weeks is a prototype — worth being honest early about which of the two you need, because they are built differently.

Can you take over an existing codebase?

Yes, and it starts with a short architecture review rather than a rewrite. Most inherited codebases have three real problems and a lot of noise; the review separates them first. Rewrites are the expensive answer and usually the wrong one.

What stack do you use?

TypeScript, Next.js and Postgres by default; Python where the work is data or models. Boring on purpose — the exciting choice only gets made when the boring one has visibly run out of room, and the day it did gets written down.

Why the data model before the screens?

Because the schema decides what the product can become. Most products that turn painful to change were painful in the schema first, and a screen can be redrawn in an afternoon while a migration cannot.

Do we get the code?

From the first commit. Your repository, your hosting, your accounts. Nothing to migrate off when the engagement ends, because nothing ever lived somewhere else.

What happens after launch?

Either a handover written so your next engineer can carry it without a call, or a retainer if you would rather keep the same hands on it. Which one it is gets decided before the build, not after.

Custom web products

What it covers

What you end up owning

Terms

Not a fit if

Questions that come up first

Related

Describe the product