12 questions to ask an MVP development agency (and how to compare proposals)

Before you hire an agency or studio to build an MVP, ask for seven things in writing: the scope, one fixed price, a week-by-week timeline, a rule for handling changes, regular demos, ownership of the code and accounts, and a defined fix period after launch. The twelve questions below cover each of these, with what a good answer sounds like. At the end is a simple way to compare proposals side by side.

#The twelve questions

#1. What exactly will be built, and where is it written down?

A good answer is a list: the types of user, the things each can do, the screens involved and the systems it connects to. It should be specific enough that you could tick items off at the end.

Be careful when the scope is a paragraph of general description. Most disagreements later in a project trace back to a scope that two people read differently.

#2. Is the price fixed, and what could change it?

A "from" price on a website is a starting point. What matters is the proposal: it should give one number for the written scope, and say plainly what would change it. The usual answer is "only a change to the scope that you ask for".

If the price is an estimate, ask for the range and whether there is a limit. Our guide to fixed price vs time and materials explains when each model suits a project.

#3. How long will it take, and what happens if it runs late?

Ask for a week-by-week plan, not a single end date. Then ask what happens if the work falls behind. With a fixed price, a late project should not cost you more. It is still worth hearing how they would tell you and what they would do about it.

#4. What happens when I want to change something mid-build?

You will. New ideas always appear once you see the product working. A good answer describes a routine: the idea is written down, you are told what it would add in time and cost, and you choose whether it replaces something in version one or waits for version two.

Two answers deserve a follow-up question. "We are flexible" can mean changes are absorbed quietly until the date slips. "No changes at all" can mean you launch something you already know is wrong. See the scope creep patterns to watch for.

#5. Who will actually do the work?

Ask who writes the code and designs the screens, how experienced they are, and whether any of it is passed to another company. Ask who you will speak to week to week. It is reasonable to want the person you talk to and the people doing the work to be close together.

#6. What will I see, and how often?

Working software, every week, is the standard to hope for. A demo on a call is good. A link where you can try the product yourself is better. If the first thing you will see is the finished product, problems surface when they are most expensive to fix.

#7. What will you build it with, and could another team take it over?

You do not need to judge the technology yourself. Ask two things: is it widely used, and could you hire someone else to work on it later? A mainstream stack with good documentation is a safer choice than something unusual or built in-house. For reference, see the SaaS MVP tech stack for 2026.

#8. Who owns the code and the accounts?

The answer you want: the code lives in a repository you own from the first day, and the hosting, database, payment and analytics accounts are in your name. Then nothing has to be handed over at the end, and nothing ties you to the agency.

Ask about license fees too. You should not need to pay to keep using your own product.

#9. What happens after launch?

Ask how long they will fix problems in what they built, and what counts as a fix as opposed to a new feature. Ask what the options are afterwards: a handover to your own team, a monthly arrangement, or neither.

#10. What is not included?

Every proposal leaves things out, and a good one lists them. Common ones are native mobile apps, formal compliance audits, translation, content, and the running costs of hosting, AI usage and other services. Ask for an estimate of the monthly running cost, so the build price is not the only number you have.

#11. How can I check your past work?

Ways to do this include a conversation with a past client, a walkthrough of a similar project, or a sample of handover documentation with the details removed. Client work is often confidential, so not every agency can offer all three. You should come away having seen something real.

#12. What if it is not working out?

Ask how either side can stop the project, what you would pay for at that point, and what you would keep. The answer should be in the contract. It is a much easier conversation to have before the work starts than in week three.

#How to compare proposals

Proposals are hard to compare because each one describes a slightly different project. Put them into one table with the same rows.

Three things help when you read the table.

1. Compare scope before price. The lowest total often covers fewer flows or leaves out design, payments or an admin area.
2. Give everyone the same brief. If each agency scopes the project itself, you are comparing guesses. A written specification makes the quotes comparable.
3. Weigh the risk, not only the cost. An hourly quote that looks cheaper carries the risk of overruns. A fixed quote has that risk priced in.

If you do not have a written specification yet, a short paid scoping phase produces one. Ours is the Scope Sprint: one week, $1,500, and the plan is yours to take to any team.

#If you are writing an RFP

A request for proposals does not need to be long. One or two pages is enough:

• The problem, and who has it.
• The main things users must be able to do.
• Systems it must connect to.
• Your budget range and target launch date.
• What you will judge replies on.
• The date you will decide.

Stating a budget range feels uncomfortable, but it saves time. It lets an agency tell you what is realistic for that amount, instead of guessing what you can spend. For a rough figure to start from, the MVP cost calculator takes about two minutes, and how much a SaaS MVP costs explains the ranges.

#How we answer these

So you can hold us to the same list, here is what our own pages say.

• Scope and price. One fixed price in a written proposal, tied to a list of what will be built. It changes only if you change the scope.
• Timeline. Four to eight weeks for most products, with a week-by-week plan in the proposal.
• Changes. New ideas are written down, and we decide together whether each one replaces something in version one or waits for version two.
• Progress. A demo of working software every week, and a preview link you can use yourself.
• Stack. Next.js, TypeScript, Postgres and Stripe, deployed on Vercel. Nothing proprietary to us.
• Ownership. The code is in your repository from the first day, and the accounts are in your name.
• After launch. A 30-day fix window on every build, then your own team or an optional monthly plan.
• Not included. Native mobile apps, formal compliance audits, translation, and third-party fees such as hosting and AI usage.
• Past work. Most client work is confidential, so we do not publish it. On a call we can walk you through relevant projects.

The details are on the MVP development page. Builds start from $9,800. Ask us the rest on a free 20-minute call.

#Bottom line

A good agency answers these questions plainly and puts the answers in writing. Get the scope written down first, ask every agency to quote against it, and compare the proposals row by row. The answers on scope, changes and ownership will tell you more about how the project will go than the price does.

Common questions.

• What should I ask an MVP development agency before hiring them?

  Start with five: what exactly will be built and where is it written down, is the price fixed and what could change it, how long will it take and what happens if it runs late, who owns the code and the accounts, and what happens after launch. The answers tell you most of what you need to know about how the project will run.

• How do I compare proposals from different agencies?

  Compare them against the same written scope. List the user flows and features each proposal covers, then line up price type, timeline, how changes are handled, who owns the code, what happens after launch and what is left out. A lower price usually means a smaller scope or more exclusions, so check those rows before the total.

• Is a fixed price better than hourly billing for an MVP?

  When the scope can be written down, a fixed price is easier to budget and puts the risk of overruns on the builder. When the scope is still uncertain, hourly billing or a short paid discovery phase is more honest for both sides. Many founders run a short scoping phase first so that a fixed price becomes possible.

• What should an RFP for an MVP include?

  One or two pages is enough: the problem and who has it, the main things users must be able to do, any systems it must connect to, your budget range and target date, how you will choose, and when you will decide. Ask every agency to answer the same questions so the replies can be compared.

• What are the warning signs when choosing an agency?

  Be careful when the scope is described only in general terms, when the price is an estimate with no stated limit, when you will not see working software until the end, when the code or hosting would sit in the agency's accounts, or when nobody can show you past work or a sample of their documentation.

• Can I ask all twelve questions on a first call?

  Not in depth. Send the list ahead so the agency can prepare, and use the call for the three or four that matter most for your project. A written reply to the rest is fine, and it is useful to have the answers in writing anyway.