When choosing an MVP agency, the deciding factor is not the tech stack or how polished the portfolio looks, but whether the agency asks you in the first meeting "which question will this MVP answer?". A trustworthy MVP agency gives clear answers, before any contract, about the hypothesis to be tested, what stays out of scope, who owns the code, how validation will be measured and what happens after launch. The nine questions and the red-flag table below are designed to help you compare those answers side by side.
This article is only about choosing an agency. If you want to know what an MVP is, its different types and where the idea comes from, see our MVP development guide.
What are the 9 questions to ask an MVP agency?
The point of these questions is not to put the agency through an exam but to make its way of working visible. How an answer is given matters as much as what it says: an answer that comes with a concrete example, a written document or a process the team can describe in detail tells you far more than a general promise.
1. How do you define the hypothesis we are going to test?
An MVP should start from an assumption to validate, not from a feature list. A good agency writes down, together with you, the assumption that would make everything else pointless if it turned out to be wrong. If the agency jumps straight to screen designs or feature estimates, what you will get is most likely not an MVP but an unfinished product.
2. What will stay out of scope, and who will defend that list?
Every MVP has two lists: what gets built and what does not. The hard part is protecting the second one. Ask the agency what it deliberately left out in a past project and how it explained that to the client. A team that says "sure, we can add that" to every request feels comfortable in the short term, but that is exactly where control over timeline and budget is lost.
3. Who will own the source code, the infrastructure accounts and the domain?
The answer should be one word: you. The code should live in a repository under your account, cloud and app store accounts should be opened in your company's name, and the transfer of intellectual property should be written into the contract. An agency that will only "hand over" the code at the end, or insists on hosting everything under its own accounts, makes you dependent on it later.
4. How will we measure validation?
Three things should be written down before any code: the assumption being tested, the metric that measures it, and the threshold that counts as a yes. Without a threshold set in advance, any result can be narrated favourably afterwards. Also ask whether event tracking ships with the first release; instrumentation added later cannot recover the data from the early weeks.
5. How often will I see working software?
The evidence of progress is not a screenshot or a slide deck, it is working software at a real address. Expecting short sprint cycles, a demo at the end of each sprint and a staging or pre-prod environment you can open yourself is reasonable. An MVP delivered in one go after months of "we are working on it in the background" reveals a wrong direction far too late.
6. How do you handle changing scope?
Scope will change in an MVP, because priorities shift as you learn. What matters is how the change is managed. A good answer sounds like this: the new request goes into the next sprint's prioritisation, we decide together what comes out in exchange for what goes in, and that decision is recorded. Both extremes, "every change is a separate quote" and "no problem, we will squeeze it in", deserve caution.
7. How do you document technical debt?
Taking deliberate shortcuts to move fast is part of what an MVP is. The problem is not taking shortcuts, it is leaving them undocumented. Ask whether the agency delivers, at the end of the project, a written technical-debt assessment that separates what must be fixed before growth from what can live as it is for a long time. That document is the foundation for the next team's work or an investor's technical due diligence.
8. Can the MVP scale, or will it be rewritten?
An honest answer usually starts with "it depends" and then gives reasons. Designing an MVP for millions of users on day one wastes time; investing in code that will be thrown away entirely wastes money. The sensible approach is to get the decisions that are expensive to change later right (data model, authentication, payments) and to favour simplicity everywhere else. Ask the agency to explain which parts are designed to last and which are temporary.
9. What happens after the MVP goes live?
The value of an MVP shows up in the data collected after launch. The length of post-launch support, how bugs are handled, how the next iteration is planned and how you could hand the work to another team if you wanted to should all be clear. An agency that treats launch day as the end of the project is really offering you half of the job.
How do you tell a good answer from a red flag?
The table below is a checklist you can use while taking notes in agency calls. A single red flag is not always a reason to walk away, but if several show up with the same agency, it is time to pause.
| Question | Good answer | Red flag |
|---|---|---|
| Hypothesis | Assumption, metric and threshold are written down together | Work starts directly from a feature list and screen designs |
| Out of scope | A written "not building" list with reasons | "We can add that" to every request |
| Code ownership | Repository and accounts in the client's name from day one, IP transfer in the contract | Code handed over at the end, accounts stay with the agency |
| Measuring validation | Event tracking ships with the first release | "Let us launch first and think about measurement later" |
| Visibility | Short sprints, an accessible staging environment, regular demos | A single delivery after months |
| Changing scope | What comes out is agreed when something new goes in | Changes are silently squeezed in, or each one becomes a negotiation |
| Technical debt | Written technical-debt handover at the end | "Our code has no technical debt" |
| Scaling | Permanent and temporary parts are separated with reasons | Certainty either way: "it scales infinitely" or "it will be thrown away anyway" |
| After the MVP | Support, iteration and handover options are clear | Launch day is treated as the end of the project |
How do you recognise a trustworthy MVP agency?
Beyond the answers to your questions, there are signals you can verify from the outside:
- Verifiable work: named, live projects you can inspect. If possible, ask for a short call with a past client.
- Willingness to say no: a team that can tell you when an MVP is the wrong answer and openly mentions work it declines.
- A written process: concrete documents such as a discovery output, sprint reports and a technical-debt document. Ask to see a sample.
- Engineering practices: code review, an automated CI/CD pipeline and a separate staging environment. Without them, frequent and safe releases are hard.
- Caution with dates and prices: a firm date or fixed price before any discovery can mean the scope was not understood, or that the risk will be passed on to you later.
Agency, freelancer or in-house team for an MVP?
Each option is the right one in some situations. The decision depends on your in-house technical capability, how many disciplines the product needs and how quickly you plan to grow after the MVP.
| Criterion | Agency | Freelancer | In-house team |
|---|---|---|---|
| Speed to start | Usually fast, the team already exists | Fast, but depends on one person | Slow, hiring takes time |
| Range of skills | Product, design, backend, mobile and DevOps together | Usually one or two areas | Limited to the people you hire |
| Continuity risk | Low, the team has redundancy | High, knowledge leaves with the person | Medium, key-person dependency is possible |
| Product knowledge staying with you | Through documentation and a handover process | Often stays in one person's head | Stays in the company by default |
| Cost structure | Per sprint or per project, flexible | Hourly or per task | Fixed salaries plus hiring cost |
| Management load on you | Project management sits with the agency | Largely on you | Entirely on you |
| When it fits | A startup that needs several disciplines and fast validation | A narrow, single-technology experiment | A company with a technical founder building a long-term product team |
If you do not have a technical co-founder, whichever option you pick, you will need someone to evaluate the agency's architecture decisions on your behalf. We explain how to cover that gap without hiring a full-time CTO in what CTO as a Service is and who needs it.
What does a typical MVP engagement look like?
Names differ between agencies, but a healthy MVP engagement usually goes through four phases. How long each takes depends on the product's complexity, its integrations and how quickly you make decisions, which is why a firm duration promised before discovery should be treated with caution.
- Discovery: the hypothesis, target user, validation metric and threshold are written down. The build and not-build lists are settled, technical risks and architecture decisions are identified. The output of this phase should be a document, not an impression.
- Sprint-based build: working software is produced in short cycles, each sprint ends with a demo in a real environment, and priorities are updated with you.
- Launch: the product meets real users. App store submission, payments, error monitoring and event tracking should be ready at this point.
- Learning loop: the collected data is compared with the threshold set in advance. The result is an input to a decision: continue, change direction or stop. The technical-debt document shows you what the next step will cost in effort.
Where do no-code and AI-generated prototypes fit?
Many founders now come to an agency not with a blank page but with a working prototype built in Lovable, Cursor, Replit or a no-code platform. That is not a bad start: the prototype makes the first version of the hypothesis concrete and speeds up the scope conversation. But screens that work do not mean the product is ready for real users; authorisation, data security, payment integration and behaviour under load are usually missing.
In that case, ask the agency: "Will you read the existing code before you promise anything?" A good team first separates what really works from what happens to work, then tells you, with reasons, whether to continue or rewrite specific parts. You can see how we handle that transition on our Vibe-Code to Production service page, and run a first check yourself with our vibe-code security checklist.
How do we approach MVPs at Detartech?
At Detartech we define an MVP in one sentence: an MVP is not a smaller product, it is the answer to a question. That is why we start with validation design rather than a feature list, writing down which assumption we will test, with which metric and against which threshold.
- We work in two-week sprints and share progress as working software in a pre-prod environment, staying in constant contact with the client throughout.
- Peer-reviewed code and an automated CI/CD pipeline are in place from day one, so releasing stops being an event.
- At the end of the project we hand over a written technical-debt assessment separating what must change before growth from what can stay as it is.
- 30 days of post-launch support are included.
You can find the details on our MVP development service page, and live examples of our work on the success stories page.
If you have an MVP idea or a prototype in hand, feel free to ask us the same nine questions. Fill in the quick quote form for a free consultation; we reply within 24 hours.
Frequently Asked Questions
Is comparing price quotes enough when choosing an MVP agency?
No, because quotes usually price different scopes. First compare how each agency defines the hypothesis, what is out of scope and how validation will be measured. A price comparison only means something once the scopes answer the same question.
Who should own the source code of an MVP?
The source code, infrastructure accounts and domain should belong to the startup from the start. The repository should be created under your account and the transfer of intellectual property written into the contract. This protects you if you later switch agencies or move to an in-house team.
How should I work with an MVP agency if I have no technical co-founder?
It helps to have an independent technical reviewer who evaluates the agency's architecture and technology decisions on your behalf. This can be a part-time technical advisor or a CTO as a Service arrangement. Also ask for every important decision to be recorded in writing with its reasons.
Does an MVP always have to be rewritten later?
Not necessarily; it depends on how the MVP was built. If core decisions such as the data model, authentication and payments were made carefully, the product usually grows through gradual improvement. A written technical-debt document shows what needs to change and when.
Can an agency take over a prototype I built with Lovable or Cursor?
Yes, in most cases. The right first step is for the agency to review the existing code before promising anything and list the gaps in security, integrations and resilience. After that review, which parts to keep and which to rewrite can be decided with reasons.
What should I prepare for the first meeting with an MVP agency?
A few sentences on the problem you solve, your target user and the most critical assumption you want to validate are enough. Competing products, an existing prototype or designs, and the date by which you need to make a decision also make the meeting more productive. You do not need a feature list; it is healthier to build that together during discovery.
