Scope and cut list
We write the feature list twice: what ships, and what is explicitly out with a reason attached. The second list is what keeps a fixed price honest in week four.
Scope with out listStartup engineering
Ship the smallest version real users can finish
An MVP is a scope decision before it is a build. We pick the one workflow carrying your riskiest assumption, build it to production standard, and instrument it so the result is a number.
- Fixed scope
- Demo in 14 days
- Full IP transfer
- 30-day warranty
What we mean by minimum
Most MVP briefs arrive as a feature list. The useful version is a sentence: the one thing you do not yet know, and the cheapest artefact that would settle it. If the unknown is technical, you want a proof of concept. If it is comprehension, a clickable prototype. An MVP is for behaviour — will a real person, with real data, finish the workflow more than once, and come back to do it again?
Two failure modes bracket this work. One is a six-figure build of a product nobody has used, dressed up with workshops and a design system. The other is a demo shipped to production — no migrations, no error handling, no second user role — which collapses the week traffic arrives. We aim at the narrow band between them: small surface, real foundations. At the end you hold a running product, behaviour data on the activation path, and a recommendation to keep building, change the bet, or stop. Stopping early is a good outcome.
| What is true of this work | What it forces | What we do about it |
|---|---|---|
| Fixed price, moving feature list | Every addition displaces something | Written out list, traded not added |
| Runway sets the deadline | Ship date fixed before scope | Cut features, never foundations |
| Founder is the only decider | Scope calls cannot wait weeks | Weekly demo on the live build |
| First real users bring bad data | Happy path alone will break | Core workflow hardened, edges plain |
| Code outlives the validation | A rewrite costs the runway | Debt register with undo costs |
In scope
- One core workflow, production standard
- Walking skeleton on real infrastructure
- Bought auth, billing and storage
- Event taxonomy and activation analytics
Not in scope
- Feasibility research on unproven technology
- Scaling and hardening after validation
- Marketing site, brand and pitch deck
Handled by
- PoC DevelopmentAnswers the feasibility question before any build.
- Software Product DevelopmentTakes a validated MVP into a roadmap.
What we build
Walking skeleton
One thin slice wired end to end and deployed to real infrastructure in the first fortnight: login, one database write, one pipeline deploy. Integration pain surfaces before unfinished screens hide it.
Deployed vertical sliceThe core workflow
The single path a user must complete for the product to mean anything, built to survive a second user role, a malformed upload, and a refresh at the wrong moment.
Hardened core workflowBought infrastructure
Authentication, billing, email, storage and error tracking come from managed services with clean exit paths. Writing your own session handling in week two is how an eight-week build becomes a five-month one.
Managed service integrationsInstrumentation for the decision
An event taxonomy agreed before code: signup, activation, the core action, repeat use. Without it launch produces anecdotes, and anecdotes always argue for building more rather than stopping.
Event taxonomy and dashboardHandover that sticks
Repository, cloud accounts and domains sit in your organisation from day one, not ours. Handover is a recorded architecture walkthrough, a runbook for the three things that break, and a named backlog.
Recorded walkthrough and runbookHow the work runs
- 01Week 1
Name the bet
We turn the brief into one testable sentence, then price a scope against it. Anything that does not move that sentence goes on the out list with a reason. You approve both lists before code.
You getSigned scope with an out list
- 02Weeks 1–2
Walking skeleton
We stand up the repository in your organisation, the pipeline, the database and one vertical slice running in production. You get a working link inside fourteen days, with the ugly integration risk already flushed out.
You getA deployed link in 14 days
- 03Weeks 3–8
Build the loop
Weekly increments against the core workflow, each demoed on the live environment rather than in slides. Edge cases are triaged into now, later or never, and the never pile is written down.
You getWeekly demo on the live build
- 04Weeks 9–10
Instrument and launch
We wire the event taxonomy and error tracking, run a private cohort through the workflow, then open it up. The memo reads activation data against the sentence from step one and names the next move.
You getDecision memo and debt register
What you are handed
- Scope document with an explicit out list
- Repository and cloud accounts in your name
- Deployed product on production infrastructure
- CI pipeline with automated checks
- Event taxonomy and analytics dashboard
- Error tracking and alerting wired up
- Deliberate debt register with undo costs
- Recorded architecture walkthrough and runbook
- Written thirty-day defect warranty
Typical stack
Product surface
TypeScriptNext.jsReactTailwind CSSshadcn/uiExpo
Core services
PythonDjango REST FrameworkNode.jsPostgreSQLRedisCelery
Bought, not built
StripeClerkAuth0ResendSupabaseCloudflare R2
Ship and observe
GitHub ActionsDockerVercelFly.ioSentryPostHog
The calls we make, and why
Monolith or services for the first build?
One deployable, modular inside — split when traffic shows seams.
Service boundaries drawn before you have usage are guesses, and each one adds a network call, a deploy target and a failure mode to a team of three. Modules inside one repository give you the same separation without the operational tax.
We’d choose otherwise whena genuinely different runtime is involved — GPU inference, long video jobs, a hard compliance boundary.
Do we buy authentication and billing or build them?
Buy — unless authentication or billing is the product.
A managed provider gives you social login, sessions, organisation invites and subscription edge cases in days rather than weeks, and none of it is what a user judges you on. That time belongs in the workflow you are actually testing.
We’d choose otherwise whendata residency, an unusual permission model, or per-seat economics make the meter the real cost.
How much of the AI feature should be real in version one?
Real enough to be judged — no scaffolding behind a queue.
If the promise is that a model does the work, faking it with a human behind a queue teaches you about demand but nothing about quality, so we build the real pipeline and the evaluation set that scores it.
We’d choose otherwise whenthe AI is a convenience on a workflow that already stands alone without it.
Is the MVP code thrown away after validation, or kept?
Kept, with a repair bill priced in writing.
Throwaway code suits a proof of concept, where the answer is yes or no. An MVP runs in production with real accounts, so rewriting it after validation discards the only asset the exercise produced. We defer deliberately and price each undo.
We’d choose otherwise whenvalidation invalidates the domain model itself — keeping that code would preserve exactly the wrong abstraction.
This fits if
- You can name the assumption that would kill the product
- You have real users ready within weeks
- You want fixed price and will cut features to hold it
- You are raising on traction, not on a deck
- A founding engineer will own the code afterwards
Look elsewhere if
- You have paying users and need scale, not validation
- The open question is feasibility — a proof of concept costs less
- Nothing on the feature list can be cut
EngagementFixed-scope build
Typical length6–10 weeks
How it startsA ninety-minute call where we try to talk you out of half the feature list.
Questions we get asked
How much does an MVP cost?
It is a fixed price agreed against a written scope, and the scope is the lever, not the rate. We quote after the scoping week, once the out list exists, so the price survives contact with week four. Moving the number down means removing workflows, not compressing the estimate.
Who owns the code and the accounts?
You do, from the first commit. The repository is created in your organisation, cloud, domain and third-party accounts are registered to your company, and IP transfers in full — no licence, no shared library you keep paying for. Our access is revoked the day we finish, and handover is a recorded walkthrough plus a runbook.
What happens when we want to add something mid-build?
We trade, not add. A fixed scope only stays fixed if new work displaces old work of similar size, so every change request comes back with what it would push out, and what it would cost as an extension instead. Changes nobody will trade anything for were never the priority they looked like.
What if it breaks after launch?
Defects are ours for thirty days after launch, at no charge, with a written definition of what counts. A defect is the product not doing what the signed scope says; a requirement discovered by real users is a change. After that window, support moves to a monthly arrangement or to your team.
How do you use AI tooling, and does that affect quality or ownership?
AI agents write a large share of the code, and every line still goes through review, tests and a pipeline before it reaches your branch. That changes the economics of a first cut, not the standard — generated code nobody can explain is the fastest route to the rebuild you are trying to avoid. Ownership is unaffected.
Often bought alongside
Tell us the requirement.
Thirty minutes with the engineers who would build it. You leave with a scope, a timeline and a fixed price — or an honest no, and the reason why.