Five Questions That Separate Good Dev Studios from Expensive Ones

Most studios say the same things on a discovery call. They talk about their process, mention Agile, show you a case study from an industry adjacent to yours, and quote a project range that somehow lands exactly where your budget sits. By the end of an hour you've learned almost nothing useful.\n\nThe problem isn't that studios are dishonest. It's that a good pitch and a good delivery team are completely different things — and the sales call is optimised for the first, not the second.\n\nHere are the five questions that actually separate the studios worth commissioning from the ones that will cost you a year of your life.\n\n## 1. "Walk me through the last time a project went sideways. What happened and what did you do?"\n\nEvery project hits trouble. A studio that has never had a scope blow-out, a client who changed direction, or a dependency that didn't exist when the project kicked off is either lying or hasn't done enough work to know what trouble looks like.\n\nWhat you're listening for isn't a perfect story — it's whether they have a clear account of what went wrong, what they did about it, and what they changed afterwards. Studios that describe failure in the passive voice ("the timeline slipped," "the brief wasn't clear enough") are pointing fingers. Studios that say "we underestimated the API complexity, we told the client within 48 hours, and we absorbed the extra week" are telling you something real about how they behave under pressure.\n\nIf they can't name a specific project and give you a specific answer, they haven't been doing this long enough or they're not being straight with you.\n\n## 2. "Who will actually be working on our project, and will they be the same people throughout?"\n\nThis is the bait-and-switch question. The senior developer who impressed you on the call is often not the person writing your code. Studios win work on the strength of their principals, then staff projects with whoever is available. That's not necessarily a problem — junior developers can do good work under proper supervision — but you deserve to know the actual team.\n\nAsk for names. Ask whether those people are employees or contractors. Ask what happens if a key developer leaves mid-project. A straight answer here tells you more about how the studio is run than anything in their portfolio.\n\nFor operators in Australia particularly, this question also surfaces whether the delivery team is offshore. That's not a dealbreaker — some very capable studios work with offshore teams — but if the answer is "our delivery partner in [city]" rather than "our team," you need to understand what that means for communication, testing turnaround, and who you escalate to when something goes wrong. The fixed-price vs time-and-materials question often hinges on this too: offshore delivery models and fixed-price contracts rarely mix well.\n\n## 3. "Show me an MVP you've shipped and tell me what you cut."\n\nAny studio can tell you they're good at scoping. Very few can show you a coherent sequence of decisions about what got dropped and why.\n\nA convincing answer here has three parts: what the client originally asked for, what the studio argued for cutting or deferring to keep the first version shippable, and what happened after launch (did the cut features actually get built, or did they turn out not to matter?). Studios that have done this well will have a story. Studios that treat scope negotiation as a purely client-driven exercise — "we build what the client asks for" — will struggle to tell it.\n\nThis matters because in most B2B ops software, the real scoping problem isn't what to build. It's what not to build in version one. A studio that has strong opinions about MVP cuts is a studio that understands software delivery. One that will implement whatever you specify is a studio that will happily build you something unusable and bill you for every hour.\n\nIf you haven't already worked through what your MVP should include, the scoping call checklist covers the questions to answer before you're in the room with a studio.\n\n## 4. "What does post-launch support look like, and what's not included?"\n\nMost studios have a support clause in their contract. Almost none of them explain proactively what it doesn't cover.\n\nThe handover period — typically 30 to 90 days after go-live — is when you find out what you actually bought. Bugs that weren't caught in UAT surface. Users ask for changes that weren't in the brief. Integrations behave differently in production than in staging. How a studio handles this period tells you everything about how much of a partner they actually intend to be.\n\nGet specifics: How are bugs reported and triaged? What's the response time for a critical issue? What counts as a bug versus a change request? Is there a retainer option if you want ongoing support? What happens at the end of the handover period — does your code go into a vault, or is there a path to continuing the relationship?\n\nStudios that get vague here often mean that post-launch is someone else's problem. That's a risk you need to price in before signing.\n\n## 5. "What would you push back on in our brief?"\n\nThis is the one question most operators never ask, and the most important one on the list.\n\nYou want a studio that will tell you when your idea is going to cause problems. Not because they're difficult, but because they've seen the same pattern before and know where it breaks. If you share your brief and the studio responds with nothing but enthusiasm, one of two things is true: your brief is unusually well-formed (possible), or they'll tell you about the problems after you've signed (more likely).\n\nThe pushback you're looking for isn't generic — "scope might grow" is not insight. You want specific: "Your plan to integrate with [system] before launch is risky because that API is notoriously unpredictable — we'd recommend building a manual workaround first." Or: "The reporting module your operations lead asked for is about three times as complex as the rest of the project — can we park it for v2?" Those answers mean someone has read your brief carefully and has a view.\n\nA studio that has no pushback is a studio that hasn't thought about your project yet. You don't want to be the place where they start thinking.\n\n## What good answers actually sound like\n\nNone of these questions have trick answers. You're not looking for studios that ace a test — you're looking for studios that talk to you like colleagues who've done this before.\n\nThe studios worth working with are a bit direct. They'll tell you something is harder than you think. They'll ask you what success looks like at six months and push you when your answer is vague. They'll have a view on whether you should build or buy the core of what you're after, rather than just defaulting to custom development because that's what pays their invoices.\n\nThe studios to avoid are polished and agreeable. They validate your timeline, match your energy, and produce a detailed proposal that somehow doesn't surface any hard decisions. By the time the hard decisions arrive — and they always arrive — you're three months in and the contract gives them cover.\n\n## One thing that makes evaluation easier\n\nBefore you start talking to studios, spend time getting your brief as concrete as possible. Not just "we need a portal for our partners" but: who the users are, what they do today without the software, what the critical workflows are, and what a good outcome looks like in six months. Studios tell you a lot about their capability in how they respond to a detailed brief versus a vague one.\n\nIf you're not sure how to structure that brief, How to Brief an AI Product Studio for B2B Ops walks through what to include and why the precision matters.\n\nThe studios worth commissioning will read a good brief and come back with better questions. The rest will come back with a quote.\n\nThat distinction will save you more time than any contract clause.