How to Choose an MVP Development Company: What to Check Before You Sign

By now you may know which kind of builder you want. If not, start with our comparison of a studio, a freelancer or an agency for your MVP. You may also have sent a short brief, as we explain in how to brief a studio for your MVP. This article is about the step between those two: you have a short list of companies, and you need to pick one. It covers what a good offer contains, how to check past work, who should own what, how pricing models differ, the warning signs in a contract, and how to compare quotes fairly.

What a good MVP partner includes

An MVP (minimum viable product) is the smallest version of your product that real people can use and pay for. Building one is more than writing code. A good partner covers five steps, and says clearly who does each one.

• Discovery. They help you cut your idea down to one user, one problem and one main path, and they write the scope down. If an offer starts with the build, ask who decides what gets built.
• Design. You see and click the key screens before the build starts. Changing a screen at this step takes minutes. Changing it later takes days.
• Build. Real accounts, each user's data kept separate, payments that handle failed charges, and working versions you can try along the way.
• Launch. Your domain, the emails the product sends by itself (sign-up, receipts, password reset), analytics and error monitoring, all in place before the first user arrives.
• Upkeep. Someone fixes problems and keeps the product up to date after launch. This should be in the offer, even as an option, not left for later.

If one of these five is missing, it is not always a problem. But you should know who does it, and what it costs.

How to check their past work

A list of logos or nice screenshots tells you very little. A product that is still live tells you much more. Ask for two or three products they built that are online today, and try them yourself.

• Sign up on your phone. Create an account, follow the main path, and see how it feels. Is it fast? Do the emails arrive? Is it clear what to do next?
• Ask what they did. Did they design it, build it, or only part of it? Who decided the scope? A clear answer is a good sign.
• Ask how old it is. A product that has run for a year or more, with updates, shows they stay after launch.
• Ask about a project that went badly. Every builder has one. A good partner explains what happened and what they changed. A company that says it never happened is less believable.
• Ask to speak to a past client. Not every client agrees to this, but a company with happy clients can usually find one.

Questions that show how they really work

Questions about price and timeline are the obvious ones. The questions below show you what working together will feel like, week after week.

• What will I see each week? You want something to click on often, not one big reveal at the end.
• What happens when I want a change in the middle? A good answer is a written process: the change is described, priced and planned before it is done.
• What happens if you are late? Listen for a plan, not only an apology.
• How do you test before launch? Ask about real phones, slow connections, and checks that one user cannot see another user's data.
• What do I get at the end, apart from the product? For example a short document that explains how it is built, so another team could take over if needed.

Who owns the code and the accounts

This is the point founders check least, and regret most. If the company keeps the accounts, you depend on them for every change, even a small one. Before you sign, make sure these are in your name, or will be moved to you:

• The code repository (the online place where the code is stored), in an account you own.
• The hosting account, where the product runs.
• The database, with all your users' data.
• The domain name.
• The payment account, so the money goes straight to you.
• The App Store and Google Play developer accounts, if there is a mobile app.
• Any outside service the product uses to send emails or track errors.

The contract should also say that the rights to the code pass to you. It is fine if the company keeps access to do its work. It is not fine if you need its permission to get your own product.

Fixed scope or time and materials?

Most offers use one of two ways to price the work.

Fixed scope, fixed price. The company writes down what it will build and gives one price for it. You know the cost before you start. The risk of the work taking longer sits with them. The limit is that changes need a new agreement, so a good written scope matters a lot.

Time and materials. You pay for the hours or days spent, often each month. It is flexible, and it can suit a project where nobody knows yet what is needed. The risk is that the total is open: if the work takes longer, you pay more.

For a first version with a clear main path, a fixed price is usually easier to plan and to compare. If you choose time and materials, ask for an estimate in writing, a maximum budget, and a short report of what was done each week.

The best quote is not the lowest number. It is the one where you can see exactly what you get, and what you do not.

Warning signs before you sign

We list the warning signs in a first reply in our guide to briefing a studio. These are the ones that tend to appear later, in the offer and the contract.

• No written scope. A price without a list of what is included, and what is not, cannot be compared or checked.
• Everything runs in their accounts. Hosting, code and domain all stay with the company, with no plan to move them to you.
• Most of the money up front. Payments split over the project, tied to things you can see, protect both sides.
• A timeline that sounds too good. A full product with many features in two weeks usually means steps are skipped.
• A price far below the market with no explanation. Ask what is left out. Often it is design, testing, launch or upkeep.
• Pressure to sign quickly. A good partner lets you take the time to compare.

How to compare quotes

Quotes are hard to compare because each company describes the work in its own way. Put them side by side in a simple table, with one line for each of these points:

• Scope. The same main path and must-have features in each quote. If one quote includes more, or less, adjust before you compare the total.
• The five steps. Are discovery, design, build, launch and upkeep each included, optional or missing?
• Changes. How are changes priced, and is a small number included?
• After launch. How many weeks of fixes are included, and what upkeep costs per month after that.
• Running costs. Hosting and outside services. Who pays them, and roughly how much at your expected size.
• Payment schedule. When you pay, and for what.
• Ownership. Code and accounts in your name, yes or no.

Then compare the cost of the first year, not only the cost of the build. A cheaper build with no upkeep can cost more over twelve months. For a sense of scale, typical market rates for an MVP are €3,000 to €15,000 with a freelancer and €15,000 to €50,000 and up with a studio or agency. Our guide to what an MVP costs explains what moves the price inside those ranges.

The bottom line

A good MVP company is easy to recognise once you know what to look for. It covers the whole path from discovery to upkeep. It shows you live products you can try. It puts the code and the accounts in your name. It writes the scope down and prices it clearly. Compare two or three offers on the same scope, over the first year, and choose the one you understand best. If you want to compare us too, see how we build MVPs and send us a few lines about your idea.