Choose the company whose proposal shows they understood what you are trying to learn, who challenged your feature list, who put a fixed price against a written scope with acceptance criteria, and whose contract gives you the code, the accounts and a clean exit. Portfolio polish and the lowest total are weaker signals than any of those.
Why choosing for an MVP is different
With an established product, you hire for capacity and reliability. With an MVP, the biggest risk is building the wrong thing or too much of it. So the vendor's product judgment and scoping discipline matter as much as their engineering. A technically excellent team that builds everything you ask for can still burn your runway.
This guide covers the MVP-specific criteria. For a general due-diligence list, with examples of good and bad answers, use our questions to ask a software development agency. If you are still deciding between a company and an individual, see agency vs freelancer.
Before you contact anyone
Write a one-page brief: who the users are, the core job the product does, the features you believe are essential, platforms, deadline, and a budget range. Send the same brief to every vendor. If you have not yet sorted features into essential and later, the prioritization method in our MVP process guide takes an afternoon and will improve every proposal you receive.
Five criteria that matter for MVPs
1. Scoping discipline
Good vendors ask about users and the business before they talk about screens. What problem, for whom, how do they solve it today, how will you know the MVP worked? Their proposal restates your goal in their own words and describes features as things a user can do, with acceptance criteria.
How to test it: count the questions they asked before quoting. A price after one thirty-minute call and no written questions is a guess.
2. Willingness to cut features
The vendor has a short-term financial interest in a larger scope. One who suggests removing features, replacing them with a manual process, or launching on one platform first is putting your outcome ahead of their invoice. That is the clearest signal of fit you will get.
How to test it: ask directly, "What would you remove from this list for a first release, and why?" Then ask, "What would you build if I had half this budget?" A vendor with nothing to say to either question will not protect your scope during the build.
3. A fixed-scope proposal
For a first release, a fixed price against a written scope caps your risk. A good one contains:
- A feature list written as user-facing capabilities with acceptance criteria
- An explicit exclusions list
- Milestones, each ending in something you can open and test
- Payments tied to those milestones
- A change-request process: changes are priced and scheduled before work starts
- Assumptions the price depends on, such as who supplies content and how fast feedback arrives
Open-ended hourly billing is not a red flag in itself, and it suits post-launch iteration well. For an MVP with a finite budget, it moves all the estimation risk onto you.
4. Ownership terms
You should finish the project able to walk away with everything. Check for:
- IP in the code and designs assigned to your company, typically on payment of each milestone
- The repository in your organization's account, or access to it from the first week
- Cloud hosting, domain, app store, payment and analytics accounts opened in your company's name
- A written list of open-source and third-party components and their licenses
- No proprietary framework or platform that only the vendor can maintain
- A termination clause that hands over all work paid for to date
5. A plan for after launch
The first weeks of real usage generate bugs and the most valuable feedback you will ever get. Ask what happens then: is there a defect-fix period, what does ongoing iteration cost, and what does handover include if you move development elsewhere? A vendor who plans for your independence is safer to depend on. BBR's version of these terms is set out on the how we work page, as one example of what to expect in writing.
Red flags
- A firm quote with no questions asked. They have priced a product they do not understand.
- Yes to everything. Every feature, every deadline, every budget. Someone is going to be disappointed later, and it will be you.
- A price far below the others. Usually a missing phase: design, testing, admin panel, deployment or store release.
- A large upfront payment. A deposit is normal. Half or more before any work is visible is not.
- Code handed over "at the end". You should see the repository throughout.
- They host it on their accounts. Convenient now, a hostage situation later.
- Vague answers about who does the work. You should know whether the people on the call are the people building it, and whether parts are subcontracted.
- Guarantees about outcomes. Nobody can promise downloads, revenue, rankings or funding.
- Equity or deferred-payment deals offered eagerly. These misalign incentives more often than they align them, and they complicate your cap table early.
- Portfolio items you cannot verify. Ask for a live link or store listing and what exactly the team did on it.
- Pressure to sign this week. A discount that expires on Friday is a sales tactic, not a capacity constraint.
Proposal comparison checklist
Put each proposal through the same grid. The total price is the last row for a reason: it means little until the rows above it match.
| Item | What to look for |
|---|---|
| Understanding of the goal | Restates the problem, users and success measure in their own words |
| Feature list | User-facing capabilities with acceptance criteria, not a list of screen names |
| Exclusions | Stated explicitly |
| Design | Included or not; number of revision rounds; clickable prototype before build |
| Admin panel | Listed, with what the operator can do |
| Testing | Own line item; devices and browsers named |
| Deployment and store release | Production setup, store submission and handling a rejection included |
| Analytics and error monitoring | Included in the first release |
| Technology | Mainstream, with a short reason for each choice. See how to choose an MVP stack. |
| Milestones | Each ends in working software on a staging link or test build |
| Payment schedule | Tied to milestones; modest deposit |
| Change process | Priced and approved before work |
| IP and accounts | Assignment to you; accounts in your name; repo access from the start |
| Post-launch | Defect-fix period; iteration terms; handover documentation |
| Team | Named roles; who your day-to-day contact is |
| Communication | Update frequency, overlap hours, tools |
| Timeline | Phases with durations; what they need from you and when |
| Total price | Compare only after the rows above are equivalent |
To judge whether a total is plausible, estimate the effort yourself using the method in the MVP cost guide. A quote far outside your own range in either direction deserves a conversation about what it includes.
Use paid discovery as a low-risk trial
You do not have to choose a vendor for the whole build on the strength of sales calls. Buy the first phase only.
What it is
A fixed-fee engagement of one to two weeks. The output is a ranked feature list, a scope document with acceptance criteria, user flows or rough wireframes for the core journey, a technical approach, and a fixed quote and timeline for the build.
How to set it up
- Agree the deliverables and a fixed fee in a short written agreement.
- State that the deliverables are yours and that you are free to take them to another vendor.
- Make no commitment to the build phase.
What to observe
- Did they meet the dates they set themselves?
- Did their questions make you think harder about the product?
- Did they push back on anything, and were they right?
- Is the written scope clear enough that a different team could build from it?
- Did the quote change from their first rough range, and did they explain why?
- How quickly and how clearly did they communicate?
After two weeks you have a document worth having regardless of who builds the product, and direct evidence of how this team works. If it went badly, you have spent a small fraction of the budget finding out. If a vendor refuses a standalone discovery and will only sell the full project, ask why.
References and proof
Ask to see something live that the team built, and ask what their role was. Client references are useful when available, but many studios work under NDAs that prevent naming clients, so absence of a logo wall is not disqualifying on its own. Products the team has released under its own name are a fair substitute, because you can install them and judge the work directly. BBR's are described in the case studies. Whatever evidence you get, weigh what you observed in discovery above what you were told in a pitch.
A simple way to decide
- Send one brief to three or four vendors.
- Drop any that quote without questions or will not put ownership terms in writing.
- Run the remaining proposals through the comparison grid.
- Commission paid discovery from your first choice.
- Sign the build only when the scope document reads like the product you want.
If you would like BBR to be one of the vendors you compare, the MVP development page explains how we scope, price and hand over a first release.