17 Questions to Ask Before You Hire a Product Studio

Hiring a studio to build your product is one of the highest-variance decisions a founder makes. The upside is a working product in a quarter. The downside is six months and most of your runway spent on something you have to throw away.

The sales call is not designed to help you tell those apart. Everyone has a nice deck, a portfolio of things that shipped, and a story about being different from other agencies. We have one too.

So here are the questions that actually discriminate. Some of them are uncomfortable for us to answer. That's the point: a question that every studio answers well isn't a question, it's a formality.

About the people who will actually do the work

1. Who specifically writes the code and designs the screens? Names, and how much of their week?

The people on the sales call are frequently not the people on the project. This is the single most common gap between what you buy and what you get. Ask for names. Ask what percentage of their time is committed. Ask to meet them before you sign, not after.

2. What's the ratio of senior to junior on my project?

"Senior-led" is a phrase doing enormous amounts of work in this industry. It can mean a principal engineer writing the core, or one senior reviewing four juniors' pull requests on Friday afternoon. Both get described the same way in a proposal.

3. How many other projects will these people be on simultaneously?

Two is normal. Four means your project is someone's context-switching overhead.

4. What happens if the person leading my project leaves?

Not a gotcha; people leave. You want to hear that there's a second person with real context, not that "the team has full documentation."

About how they actually work

5. Can I see the codebase and the design files during the project, or only at delivery?

There is exactly one correct answer, and it's "any time, here's the repo." A studio that hides work in progress is managing your perception, not your product.

6. What does a normal week look like from my side?

You want a specific answer: a demo cadence, a written update, a channel where you can ask a question and get an answer the same day. "We'll keep you posted" is not a process.

7. When you disagree with something I ask for, what happens?

This is the question I'd most want a founder to ask us. A studio that says yes to everything is optimizing for the relationship, not the product. You are paying for judgment. If they never push back, you're paying for typing.

8. Show me something you talked a client out of building.

The best answer to this question is a specific story with a specific outcome. The absence of any such story means either they've never had the conversation or they've never won it.

9. How do design and engineering hand off to each other?

Listen carefully here. If the answer involves a formal handoff (specs, annotations, a review gate, a QA pass to catch discrepancies), you're paying for coordination overhead that exists because of how they're organized, not because your product needs it. Ask what percentage of the budget that consumes. Most studios have never calculated it.

10. What's the smallest version of my product you'd be willing to ship?

A studio that can only describe the version you asked for is transcribing your spec. You want the one that comes back with something meaningfully smaller and a reason.

About money and risk

11. What's excluded from this proposal?

The inclusions list is marketing. The exclusions list is the contract. Ask for it explicitly, in writing.

12. Your estimate will be wrong. What happens then?

Every estimate is wrong. The question is who absorbs it and when you find out. "We'd have a conversation" is fine if it comes with "and here's the point in the timeline where we'd flag it." A studio that claims their estimates hold is either lying or hasn't shipped much.

13. What do I own on day one after we finish?

Repository, cloud accounts, domain, design files, third-party service accounts: all in your name, all under your billing. Any of these sitting in the vendor's account is leverage they haven't told you they're holding.

14. What does it cost to keep the lights on after launch?

Hosting, monitoring, dependency updates, security patches. Someone has to do it. Find out whether that's you, them, or nobody.

15. What happens if I want to leave mid-project?

You want a clean answer: notice period, work handed over in a usable state, no penalty beyond work already done. Studios that make exit expensive are pricing in the fact that some clients will want to.

About whether they've actually done this

16. Which of your case studies is the one that went badly, and what happened?

Every studio has one. The ones who'll tell you about it have learned something. The ones who claim they don't either haven't shipped enough or aren't being straight with you.

17. Can I talk to a client whose project didn't go perfectly?

Reference calls with happy clients tell you nothing; nobody offers a bad reference. Asking for a hard one is unusual enough that the reaction itself is the answer.

The signals underneath the answers

Past the specific questions, there are a few patterns worth watching for.

Speed of the "yes." A studio that agrees to your full scope, timeline, and budget in the first call hasn't thought about it. They're closing. The right response to an ambitious brief includes at least one "that part concerns me."

Whether they ask about your users. Studios that ask exclusively about features, stack, and timeline are order-takers. Studios that ask who your user is and what happens if you're wrong about them are partners. It's audible within ten minutes.

How they talk about their last client. Warmth means the relationship worked. Mild contempt ("the client kept changing their mind") means you'll be described that way to the next founder.

Whether the proposal reads like it was written for you. Boilerplate with your logo dropped in is a preview of the engagement.

And the questions you should ask yourself

The hiring decision fails from your side of the table at least as often as theirs. Before you shortlist anyone:

• Do you know what "working" means? If you can't say what outcome makes this project a success, no studio can build toward it. They'll build toward the spec instead, and the spec is a guess.
• Do you have someone who can decide? Projects stall on unanswered questions far more often than on hard engineering. Someone on your side needs authority to say yes in under 48 hours.
• Is your budget the whole budget? If you spend all of it reaching launch, you have nothing left to act on what launch teaches you. Hold back a meaningful reserve.
• Are you buying a product or buying a team? A fixed deliverable and an ongoing partnership are different purchases with different contracts. Being unclear which one you want is how engagements go sideways in month three.

Why we published this

These questions are not friendly to us. Number seven, nine, sixteen, and seventeen are the ones we'd have to answer carefully, and we've lost work by answering them honestly.

We wrote them down anyway because the failure mode we keep seeing (a founder six months in with a product they can't ship and can't pivot) usually traces back to a hiring conversation where nobody asked anything real. That's bad for founders and, over a long enough horizon, bad for everyone who does this work seriously.

Ask these of us. We'd rather answer them now than have you find out later.

Start the conversation →