In this guide 6 sections
Ask five things in writing. Who draws the scope line and signs it off? What happens to a request outside it? Are usage tracking and payments included? Who owns the code and the data? Who supports the pilot after release? Teams that answer plainly are easier to compare, and the vague ones show themselves quickly.
Who owns the scope line?
Every MVP lives or dies on one list: what is in the first release and what is not. Ask the team who writes that list, who approves it and what the signed document looks like. Ask whether the sheet also records the user roles, the devices supported and the third party systems that are deliberately left out. Those lines settle most later arguments.
A good answer names a person on their side, a person on yours and a dated scope sheet. A weak answer is a long feature spreadsheet that nobody has ever cut. Ask to see a past scope sheet with the client name removed.
Listen for whether they push back on your ideas. A team that agrees to every feature in the first call is pricing hope, not work.
- A named owner of the scope list on both sides
- A dated sheet of what is in, what is out and what waits
- The single user journey the release must prove
- Who may change the list after sign-off
What happens to a request outside the scope?
It will happen in the third week. A cofounder sees a competitor’s screen and wants a filter, a chat box or an export to Excel. Ask now how that request is handled.
The healthy pattern is short. The request goes on a parked list, gets a rough effort note and waits for the next planning slot. Nothing enters the build silently, and nothing is refused without a reason. Ask for an example from a past project where a late request was parked, and how long the founder waited before it was scheduled into a later release.
Ask whether a swap is allowed: one item out, one item in, same timeline. Teams that only know how to say yes or send a change order tend to blow up the schedule.
Are usage tracking and payments in the price?
Founders often discover these two late. A pilot without step events cannot tell you where users gave up, and a pilot that cannot take a payment cannot test willingness to pay.
Ask whether event tracking on each screen of the core journey is part of the quote. Ask which payment gateway they have wired before, how refunds are handled and whether a test mode is used during the pilot. Pay attention to how they describe the pilot readout, since a dashboard that only shows total sign-ups will not tell you which screen lost people.
If either item is priced separately, that is fine. Silence is the problem.
- Step events on sign-up, first action and repeat action
- A dashboard or export you can read without a developer
- Payment gateway, refund path and invoice copy
- Email or SMS provider for sign-in codes
Who owns the code and the data?
Ask for the answer in the contract, not on a call. The code repository should sit in an account under your company name, with the team added as contributors. Domain, app store listings and cloud accounts follow the same rule. Ask the same of app store developer accounts, push notification keys and the analytics workspace, since these are the pieces that are painful to transfer after a falling out.
Then ask about the data. Where do user records live, who holds the database password and how would you take a full export if you parted ways next month?
Check what third party libraries and templates the team reuses, and under which licences. Reuse is normal. A surprise licence on a paid template is not.
- Repository under your company account
- Cloud, domain and store accounts in your name
- Database export in a readable format on request
- Licence list for reused libraries and templates
How is the pilot supported after release?
Release day is the start of the test, not the end of the project. Ask who watches errors in the first two weeks, how fast a blocking bug is fixed and whether a fixed number of hours is held back for pilot changes. A team that offers a named engineer for those two weeks, and a written response time for a blocking fault, is describing something you can hold them to.
Ask also what the team does with what the pilot shows. A good one sits down with you, reads the usage data and helps decide between stop, fix or continue into the full product.
Before you shortlist, write your five questions on one page and send the same page to every team. Compare the replies side by side.
MVP team questions sheet
Table of five rows, one per question group: scope line, outside requests, tracking and payments, ownership, pilot support. Columns hold the question, each team’s written answer, a red, amber or green mark and a line for follow-up. A final row records who you would trust to say no to you.
Open a blank worksheet to printQuestions owners ask
How many teams should I compare?
Three is usually enough. Send the same question sheet to each and judge the written replies. More than that adds meetings without adding clarity. Compare the replies on named roles, dated documents and stated response times. A vague team cannot fake those.
Should I ask for a fixed price?
Ask for a fixed price against a signed scope sheet. If the scope moves, the price moves in writing. A fixed price with no scope sheet is only a guess dressed up.
Is it a bad sign if a team refuses to share past work?
Not always, since many contracts forbid it. Ask instead for a walkthrough on a call, a reference you can phone or a sample scope sheet with names removed.
What if I have no technical background?
Judge the process rather than the code. Clear scope papers, plain replies and a named owner for each decision are visible to anyone. Ask a technical friend to read the ownership clause only.