Questions to Ask MVP Developers Before Signing

The most useful questions to ask MVP developers before you sign are about scope, ownership, change and exit, not about the stack or the hourly rate. Founders rarely lose a first release to a bad framework choice. It goes wrong in the contract: nobody wrote down what was left out, the code sat in the vendor’s account, or a small change turned into a new invoice.

Our Ahmedabad team builds first releases for American, British and Gulf founders, so we hear these from the other side of the table. Below are the twelve we think matter most, grouped in the order we would ask them, with the answers we would want to hear. If you would rather talk to a team that answers them in writing, you can hire a dedicated MVP team from us and ask all twelve on the first call.

Questions to ask MVP developers about scope

Scope comes first because it is where first releases are won or lost. Neither question costs anything to ask, and a team that has shipped few first releases will find both awkward.

1. What would you cut from my first release?

Hand over your full feature list and ask what goes. An experienced team answers quickly and gives a reason for each cut, along the lines of: “Leave the mobile app and the reporting screens for later. Keep sign-up, the core journey and one way to pay, because together they show whether anyone will pay.” Every cut should trace back to the one thing the release has to prove.

Watch for the opposite: a team that accepts every item and prices the lot. That is easy revenue for them and a long first release for you. A list that does not shrink in the first conversation seldom shrinks afterwards. Our guide to MVP cost shows how quickly each added feature moves a build up its range.

2. Where will “not in version one” be written down?

In the scope document, as a list of its own. A useful exclusions list is specific enough to settle an argument three months later:

• “No Android app: iOS and a responsive web app only.”
• “Card payments through one provider; no refunds or invoicing screen.”
• “English only, and a single owner account with no admin roles.”

You can then plan release two from that list rather than from anyone’s memory of a call. On our fixed-scope projects we quote the price with every exclusion named, and anything outside the document gets its own quote before work starts. A scope that names only what is included leaves “it was implied” as the vendor’s argument when the first disagreement comes.

Who owns what: ask your MVP developers early

Of all the questions to ask MVP developers, these two take the least time and decide the most: who controls the product if the relationship ends badly. Ask them before price comes up.

3. Who owns the code, and which clause says so?

You want to hear “you do, from day one”, followed by a clause number. The clause matters more than the sentence, and US copyright law shows why. Under 17 U.S.C. § 101, a commissioned work is “made for hire” only if it is ordered for one of nine listed uses, such as a translation, a compilation or part of a motion picture, and both sides sign a written agreement saying so. Software is not one of the nine, so a contract that simply labels custom code “work for hire” may not make you its owner. Code written by the vendor’s own employees belongs first to the vendor, as their employer.

What moves ownership to you is an assignment, and § 204(a) says a transfer of copyright is not valid unless it is in writing and signed by the owner of the rights or their authorized agent. That is our reading of the statute, not legal advice: have your own lawyer read the clause, especially if your company is outside the US.

One follow-up while you are there: does the assignment reach everyone who touches the code? If the vendor uses freelancers or subcontractors, ownership has to pass from each of them to the vendor and then to you. We use no subcontractors, so our chain has one link. A team that does use them should be able to show you how theirs is covered.

4. Which company holds the accounts?

Code is one asset among several. Ask who will be the registered owner of each of these:

• the code repository
• the cloud account and the database inside it
• the domain
• the App Store and Google Play listings
• the analytics property and the payment provider

The right answer is your company, for all of them, from the first week, with the vendor added as a user. That is how we set it up: the repositories and cloud accounts sit in your name, and you have commit access from week one. Be wary of “we’ll host it on ours for now and move it at launch”. Moving a live database and its credentials out of someone else’s account turns into a separate job. You would be negotiating it with a vendor who has already been paid.

What to ask MVP developers about price and change

Here you are choosing how risk is shared as much as choosing a number, and the same team can suit one product and not another.

5. Fixed scope, time and materials or a dedicated team: which fits this product?

A vendor you can trust will name the model that fits your case and the one that does not, rather than whichever is easiest to sell. We offer all three, so here is the trade-off as we explain it to founders:

For a first release you can describe, fixed scope is usually the safest choice. Time and materials suits a founder who expects week three to change the plan. A vendor with one model that supposedly fits everyone is giving you a sales answer. Our breakdown of custom software pricing covers how each one is billed.

6. What happens when I change my mind?

You will change it; putting a prototype in front of real users usually sees to that. So ask for the steps, not a reassurance. On our fixed-scope work a change runs like this:

1. You raise it. A message is enough.
2. Within 48 hours you get a written quote: the price, how far the date moves, and what would have to drop if the date must hold.
3. No work begins, and nothing reaches an invoice, before your written yes.
4. The scope document is amended the same day, so only one version of the scope is ever live.

If the answer you get is “we’re flexible, don’t worry about it”, worry a little. Flexibility without a written price tends to turn up later as a larger final invoice.

Questions to ask about the MVP developers themselves

Whatever the contract calls it, you are hiring people, and the person running the sales call is rarely the one who will write your code.

7. Who exactly will work on my product?

Ask for names, roles and years in the stack, then how much of each person’s week is yours. A typical answer is short: a lead, one or two engineers, a designer and someone on QA. Two follow-ups matter more than the list itself. Are the people in the proposal the ones who start on day one? And what happens if one of them leaves halfway through?

“A team of senior engineers” with no names attached is not an answer. On our MVP team page we commit to real profiles within 48 hours and to you interviewing every engineer before they join, which is a reasonable standard to hold any vendor to.

8. Can I try them before I commit?

Yes, if the vendor is confident in its people. A short paid trial on your actual problem shows how a team asks questions, writes things down and keeps pace, which no portfolio can. Ours is a two-week scoping sprint in which the team pins down the smallest version worth building, designs the key flows and gets the repository ready. If the fit turns out wrong, you stop there, pay for those two weeks only and keep the scope document and the designs.

A vendor who insists on the full commitment before any small start is asking you to carry a risk it will not.

Progress: ask MVP developers what you will see

An MVP runs for weeks, not months, so a month in which nobody sees the work is a large slice of the whole schedule.

9. How many weeks to launch, and when do I see the first working piece?

For a focused first release, six to ten weeks counted from the scoping sprint is a realistic range, and it is the one we quote on our MVP pages. Be careful of either extreme. Three weeks for a complicated product usually means shortcuts that come due in version two; six months for a single flow usually means the scope was never cut. Ask the team to walk you through the weeks and to say which assumptions would stretch them.

Then ask when working software first appears, and how often after that. On our start-up MVP builds you can click through a prototype in week two. After that you see a working slice every week, in a demo you attend, with a short written note on what landed and what moved. Time-and-materials work runs on a two-week cycle instead. Each sprint closes with a demo and a short written report. Between demos you should be able to open the board and read the repository yourself. “We’ll show you when it’s ready” usually means you see it when it is too late to change.

10. How do you test it, and what do I sign off against?

Look for a named person responsible for QA and a written result at the end: a test summary and a list of known bugs, so that sign-off rests on more than “it looks fine to me”. Our fixed-scope milestone for a finished build delivers exactly that pair of documents.

Then press on the dull parts. Who tries the sign-up and payment path on a real phone? Is there a security pass before launch? A team that tests only what it demoed leaves everything else for your first users to discover.

Launch and exit questions to ask MVP developers

Founders skip this part more often than any other and regret it most. A contract is not finished until you know how it ends.

11. What happens in the month after launch?

Launch should mean the product running in your accounts, with the repositories, documentation and a walkthrough handed over. Next, ask who fixes a defect that turns up on day four, how quickly, and for how long that cover lasts. On our fixed-scope projects the launch milestone includes 30 days of support, so an early bug does not become a fresh quote.

Check, too, that analytics are wired in from the first day. A release that cannot tell you how many people finished the main journey has launched without learning anything, and learning is the reason an MVP exists.

12. If we part ways, what do I leave with?

Ask for the full list, in the contract: repositories, accounts, documentation and credentials, all usable without the vendor’s help, plus a notice period you can live with. Monthly work with us carries no annual contract and stops on 30 days notice; the code stays yours however it ends. A vendor who goes quiet at this question has shown you how the ending would feel.

Putting these questions to MVP developers

You do not need all twelve on one call. Get ownership, the accounts and the exclusions list in writing first, because they are the hardest to repair once you have signed. Then compare how each vendor reacts. Treat this list of questions to ask MVP developers as a filter rather than a script: a team that is comfortable with it usually has the answers on file already, and a team that turns vague at question 3 or 4 has told you what you need to know.

Write the answers into the contract rather than keeping them as things you were told on a call. A promise a vendor will not put on paper is one you cannot enforce. If you are still deciding what the first release should contain, start with what an MVP costs and what drives it and bring your list to the call.