The moment you wire a deposit, your options narrow. These twelve questions are not about vetting capability — any studio worth considering can build your MVP. They test honesty: specifically, whether a studio is honest about ownership, continuity, and cost. Most good studios answer them cleanly. Most expensive mistakes start here.
For the broader operational checklist — point of contact, default stack, staging URL timing — read what to ask a product studio before you sign anything. This list is for the ten minutes before you hand over money.
Who is actually writing your code?
1. Who specifically writes the code?
Not the studio name — a person. Ask whether they are a full-time employee or a contractor, and what their current project load is. A studio that names someone specific and can tell you their stack is structurally different from one that says "our delivery team."
Good answer: "This is our senior engineer. Full-time, across two other projects right now."
2. What percentage of the work is in-house vs subcontracted?
Some studios subcontract core pieces without disclosing it. You hired the studio — if a third party writes the auth layer, your recourse on quality is different from what you negotiated. Ask before you pay.
Good answer: "100% in-house. We do not subcontract without your written approval."
3. What is the bus factor on my codebase?
If one person holds the knowledge and they leave mid-project, you are rebuilding from a partial handoff. Ask how knowledge is distributed across the team and what the continuity plan looks like if the primary engineer exits.
Good answer: "Two engineers are across the codebase. Any departure triggers a documented two-week overlap."
Who owns the IP from day one?
4. Who owns the IP and code from day one?
Some studios retain IP until final payment. This means they hold your code during any dispute — and a dispute is exactly when you need to be able to walk away with your work. Full IP assignment from the first commit, written and named as a contract clause, is the clean version.
Good answer: "IP assigns to you at first commit. It is clause four in the contract."
5. Can I access the repository before handover?
Owner-level repo access from day one removes the ability to hide progress. A studio that delays repo access until the final milestone is one that controls information as a negotiating position. On every engagement we run, the client is added as a repo owner before the first commit goes in.
Good answer: "Before we push the first commit."
6. What does the written scope document look like?
Verbal scopes are not scopes. The contract should define goals, non-goals, milestone criteria, and the change-order process before work starts. Ask for a redacted example from a previous project. A studio that has never written a formal scope will produce something vague under pressure. We cover the one-page standard in Contracts before code.
Good answer: "One or two pages. Here is a redacted example from a recent project."
What happens when something goes wrong?
7. How do you handle scope changes in writing?
Every build will have scope changes. The question is whether the studio has a written change-order process — you get a write-up and approval before they build it — or whether they absorb changes silently and adjust the final invoice without warning. Silence is not generosity; it is deferred billing.
Good answer: "Written change order, signed off before we touch it. The contract defines material change as anything over a day of work."
8. What does post-launch support cost?
"We will handle it" is not a support model. Bugs surface in production. Dependencies update. Ask specifically: what is the retainer rate, what is the response time, and what is out of scope. What an MVP actually costs covers the ongoing infrastructure numbers that never appear in a build quote.
Good answer: A named monthly rate, a defined response time, and a clear list of what is included.
9. What is the exit clause if the engagement is not working?
A studio confident in its work offers a clean exit at milestone boundaries: IP assignment, code handover, and partial refund if the next milestone has not shipped. A studio that resists this is betting on your sunk cost.
Good answer: "Exit at any milestone. IP transfers immediately. Partial refund prorated to the remaining milestone value."
What does this actually cost beyond the build quote?
10. What hidden costs are not in the headline build number?
Third-party API fees, hosting, AI inference, and post-launch maintenance are almost never in the build quote. Set aside 15–20% of the build cost per year for maintenance, and budget $100–$200 per month for infrastructure before meaningful traffic. A studio that does not name these upfront is avoiding the conversation.
Good answer: A specific list of likely ongoing costs with realistic ranges.
11. What triggers each milestone payment?
Milestone-based billing is standard. What varies is whether the milestone criteria are named. "Completion of phase two" is not a milestone definition — it is a dispute waiting to happen. Ask what observable, specific state the product must be in for each payment to release.
Good answer: "Payment two releases when the staging environment is live, auth works, and the core workflow runs start to finish."
12. What is in the handover package?
A build that hands over code without documentation creates dependency. The handover should include a deploy guide, environment variable documentation, a data model overview, and the recurring maintenance tasks. Ask what a handover looks like before the engagement starts, not the week before launch.
Good answer: "Deploy guide, data model, environment setup, and a recorded walkthrough of the admin and key flows."
| Question | Red flag | Clean answer |
|---|---|---|
| Who writes the code | "Our delivery team" | A name and a current project load |
| Subcontracting | "Handled internally" | "Zero, without your written approval" |
| IP ownership | "On final payment" | "From commit one, named in the contract" |
| Repo access | "At handover" | "Before commit one" |
| Scope changes | "We will sort it out" | Written change order within 24 hours |
| Exit clause | None offered | Named terms at every milestone boundary |
Heuristics
- The contract is the truth, not the pitch. Ask for a sample contract before you sign. A studio that will not show one will write it in their favour when it matters.
- IP and repo access are binary. You either have them from day one or you do not. There is no acceptable "later."
- The exit clause reveals confidence. A studio that offers a clean early-exit at every milestone is one that does not expect the relationship to break down — and that confidence shows up in the work, not just the contract.
Written 2026-06-19 by Naman Barkiya.