Founder's Guide: How to Hire an MVP Agency Without Getting Burned

Roughly half of the first-time non-technical founders we have a 30-minute call with start the conversation by describing a previous MVP build that went badly. The story varies in detail but the structure is always the same:

• A “fixed-price” quote that turned out not to be fixed.
• A timeline that doubled.
• A codebase the founder couldn’t audit because they don’t read code.
• A handover that wasn’t really a handover — keys, accounts, and tribal knowledge stayed with the agency.
• A “phase 2” pitch when the dust settled.

The amounts vary. The smaller burns are £30–£60K. The bigger ones cross £200K. The pattern is the same.

This post is the diagnostic. If you’re talking to agencies right now and want to spot the bad ones before you sign, here’s the checklist.

Signal 1: They quote a price before they quote a scope

A genuine fixed-price engagement requires a fixed scope. A statement of work that says “build the MVP” is not a scope. A scope is:

• Specific user flows enumerated (signup, the three core actions, settings, billing)
• Specific data models named (users, accounts, the central business entity, billing)
• Specific integrations listed (auth provider, payments processor, email sender, observability)
• Specific deliverable artefacts (running web app, mobile app, both, what infra it runs on)

If the agency quotes a price before this document exists, the price is fictional. They are bidding low to win the engagement and will charge change orders for everything the original scope didn’t cover. That’s how a £45K quote becomes a £110K final invoice.

Signal 2: Your code is in their repo

The first contractual non-negotiable: code lives in your GitHub organisation from commit 1, not in the agency’s repo with a promise to transfer at the end.

The agency-side argument is operational convenience. The founder-side reality is leverage. If the code is in the agency’s repo and you’ve paid 80% of the engagement so far, you have no ability to walk if the relationship deteriorates. The remaining 20% can hold the entire build hostage.

We’ve helped two founders recover code from agencies that wouldn’t transfer it at the end. Both times the legal cost approached the original build cost.

This is preventable in clause 1.4 of the SOW. If the agency resists, walk.

Signal 3: No production access until “after handover”

Production access — AWS or GCP or Azure account ownership, domain ownership, database credentials — should be yours from week 1. The agency operates within your accounts using their own user identities. When the engagement ends, you revoke their access.

The alternative pattern — agency owns the cloud account, deploys for you, “we’ll transition it at the end” — is the same hostage pattern as the repo. Production keys are even higher leverage than code.

The healthy version: you sign up for AWS today, you add the agency’s engineering team as IAM users today, they build inside your account. The day the engagement ends, you remove their access. The full system, including all credentials and infrastructure, is already yours because it always was.

Signal 4: Their warranty is “best efforts”

Software has bugs. A serious agency stands behind the build with a defined warranty period — typically 90 days from delivery — during which bugs in the originally-scoped functionality are fixed at no charge.

“Best efforts” is not a warranty. Neither is “we’ll be there for support, just pay for the time.”

What you want in the contract:

• 90-day warranty on shipped scope
• Specific definition of what constitutes a warranty bug vs a change request
• A response-time SLA (e.g. 48 business hours for triage, severity-based fix windows)
• An hourly support rate for post-warranty work, agreed in advance

This protects both sides. The agency knows what they’re committing to. You know what you’re getting.

Signal 5: No real references

A serious agency will give you three references from clients with completed engagements. You should call all three.

The questions:

• Did the scope hold or did it sprawl?
• Was the timeline met?
• Did the agency stay engaged through the warranty period?
• Was the handover clean — code, infrastructure, documentation, accounts?
• Would you hire them again?

The reference call where the answer to question 5 is “I would, but only on a different kind of work” is the most informative one. That’s a candid reference. A reference that gives unqualified praise to every question is either coached or unusual.

What good looks like

A productized engineering engagement that’s structured correctly looks like this:

• SOW with enumerated scope, deliverables, timeline weeks, total fixed price.
• Code in your GitHub from commit 1.
• Production infra in your cloud account from day 1.
• Bi-weekly demos against the original scope.
• 90-day warranty on shipped functionality.
• A defined hourly rate for change orders, agreed in writing.
• A clean handover at the end — repo, docs, runbooks, ops handover meeting, support contact for warranty issues.

This is how we run every Build engagement. It’s also how every serious productized engineering firm runs them. The agencies that resist this list are the ones you walk away from.

What we ship

Fixed-price Build engagements for non-technical founders, typically 8–16 weeks depending on scope, with everything above written into the SOW. The MVP cost calculator linked below gives honest benchmarks for what your specific build should cost. Three minutes, no signup, emailed memo includes a fillable SOW template.

If you’ve been burned before, the questions in this post are also useful screening questions for any other agency you’re evaluating.

Read more: /build/ · /method/ · /calculators/mvp-cost