I've been on both sides of this conversation more times than I can count. Building software for 25 years means I've hired development studios, been hired as one, and watched countless projects crater because the wrong questions got asked upfront.

This article is part of our complete guide to hiring development studios.

Here's the thing: most articles about vetting development partners read like they were written by someone who's never actually built software. They'll tell you to ask about "agile methodologies" and "quality assurance processes" — checkbox questions that every studio has canned answers for.

We're going to skip that noise. These are the questions I ask when we're the ones hiring external help at Dazlab.digital. They're designed to expose whether a studio actually knows how to ship working software or if they're just good at PowerPoint.

1. "Show Me Your Graveyard"

Every development studio has a portfolio page. Shiny logos, success stories, testimonials from thrilled clients. That's table stakes. What you really want to see is their graveyard — the projects that died, pivoted hard, or straight-up failed.

Why? Because failure tells you more about a studio than success ever will. A studio that can't point to failures either hasn't been around long enough to matter or they're not being honest with you. Neither is a good sign.

When they show you their failures, listen for ownership. Do they blame the client? Market conditions? Mercury in retrograde? Or do they talk about what they learned and how they changed their process? The best studios treat failure like expensive education — they paid tuition and got smarter.

At Dazlab.digital, we've had our share of projects that didn't work out as planned. One early real estate software project taught us that domain expertise matters more than technical chops. We could build anything, but we didn't understand how real estate associations actually operated day-to-day. That failure shaped how we approach every vertical SaaS project now — we embed ourselves in the industry before writing a line of code.

2. "Walk Me Through Your Last Three Deploys"

This question cuts through the BS faster than anything else I've found. You're not asking about their deployment process in theory — you want to hear about what actually happened last Tuesday at 4 PM when they pushed code to production.

Good studios will tell you stories. They'll mention the minor heart attack when a migration took longer than expected. The scramble when a third-party API changed without warning. The relief when their rollback strategy actually worked. These are the details that prove they're actually shipping software, not just talking about it.

Bad studios give you a textbook answer about CI/CD pipelines and automated testing. Sure, those things matter, but if they can't tell you about real deploys with real complications, they're either not deploying often enough or they're not being straight with you.

What you're really evaluating here is their relationship with production. Studios that treat production like a scary place you visit twice a year will build you scary software. The ones who deploy constantly have systems, muscle memory, and battle scars that make your project safer.

3. "Who Writes the First Line of Code?"

This might seem like a weird question, but the answer tells you everything about how a studio actually operates. In the best studios, senior people write the first lines of code. They set patterns, make architectural decisions, and establish the technical direction before handing off to the broader team.

If the answer is "our junior developers start coding while seniors review," run. That's a recipe for rework, technical debt, and projects that grind to a halt when someone realizes the foundation is wrong.

I've seen too many projects where studios treat senior developers like reviewers instead of builders. They sit in meetings, review pull requests, and occasionally swoop in to fix things. That's backwards. The most critical code — the stuff everything else builds on — needs your most experienced hands on the keyboard.

At Dazlab.digital, I still write code on every project we take on. Not because I don't trust our team, but because those first architectural decisions cascade through everything else. Getting them wrong means fighting uphill for the entire project. Getting them right means even junior developers can be productive from day one.

4. "How Do You Handle Scope Creep When It's Your Fault?"

Everyone asks about scope creep from the client side. "What if we want to add features?" "How do you handle change requests?" Those are kindergarten questions with kindergarten answers involving change orders and project managers.

The real question is what happens when the studio causes scope creep. When their architect realizes the approach won't scale. When they discover a dependency nobody caught during planning. When their estimate was just plain wrong.

Good studios have seen this movie before and have clear policies. Maybe they eat the cost up to a certain percentage. Maybe they split the overage. Maybe they have a specific process for resetting expectations. The details matter less than the existence of a plan.

Bad studios act surprised every time. They'll make it seem like your project is uniquely complex, that nobody could have foreseen these complications. That's nonsense. Software estimates are wrong by default — the question is how wrong and who pays for it.

One studio we worked with had a brilliant policy: they tracked estimation accuracy across all projects and used it to pad future estimates. After a year, they knew their Rails projects ran 20% over on average, so they built that into pricing. Honest, transparent, and nobody felt ambushed.

5. "Tell Me About a Time You Fired a Client"

This question makes people uncomfortable, which is exactly why you should ask it. Studios that have never fired a client either haven't been in business long enough or they're so desperate for revenue they'll tolerate anything.

The best studios know that some client relationships are toxic to their team, their culture, and ultimately their ability to deliver great work. They have boundaries and they enforce them. When they tell you about firing a client, listen for professionalism and lessons learned, not bitterness.

We've fired exactly two clients in our history. One consistently verbally abused our developers during code reviews. The other kept trying to bypass our process and assign work directly to individual developers through LinkedIn. Both taught us to screen for cultural fit as much as technical fit.

A studio that's willing to fire bad clients is also a studio that will push back when you're about to make a terrible decision. They're not just order-takers — they're partners who care more about outcomes than invoices.

6. "How Much of Your Codebase Is More Than Two Years Old?"

This question reveals whether a studio builds software that lasts or if they're in the business of perpetual rewrites. The answer you want isn't 0% (that means they can't maintain anything) or 100% (that means they're not growing). You want something in the middle with a story behind it.

Good studios will tell you about core libraries they've maintained for years, battle-tested patterns they reuse across projects, and yes, some legacy code they're not proud of but that still ships value every day. They understand that software is a living thing that needs both stability and evolution.

Bad studios either rewrite everything constantly (expensive for you) or they're still deploying the same WordPress setup they used in 2015 (limiting for you). Both extremes suggest they don't understand the economics of software development.

The best answer I ever heard: "About 40% of our codebase is our core framework that we've evolved over five years. Another 30% is project-specific code from the last two years. The remaining 30% is stuff we'd love to refactor but it works and our clients' businesses depend on it, so we maintain it carefully and improve it incrementally."

That's a studio that understands trade-offs.

7. "What's Your Position on AI-Native Development?"

I'm not asking this because AI is trendy. I'm asking because their answer tells you if they're paying attention to where software development is heading or if they're still partying like it's 2019.

You don't need them to be AI evangelists. In fact, be wary of studios that want to sprinkle AI on everything like it's magical fairy dust. What you need is a thoughtful position on when AI makes sense, when it doesn't, and how they're adapting their development practices.

The best answers acknowledge both the potential and the limitations. They might tell you about a project where AI-powered features delivered real value — like automated document processing for an HR tech platform. They'll also tell you about times they pushed back on AI features that were just expensive distractions.

At Dazlab.digital, we've found AI most valuable in specific contexts: document understanding, pattern matching in large datasets, and natural language interfaces for complex queries. We've also wasted time trying to use AI for things better solved with conventional code. A studio that can't tell you both sides of that story isn't being honest about their AI experience.

8. "If This Project Fails, What Will Be the Most Likely Cause?"

This is my favorite question because it forces radical honesty. Every project has failure modes. Every collaboration has weak points. A studio that pretends otherwise is either lying or naive.

Good answers are specific and self-aware. Maybe they'll say: "The biggest risk is usually requirements drift — when stakeholders realize what they actually need is different from what they asked for." Or: "In our experience, projects fail when there's not a clear internal champion who can drive adoption after launch."

Bad answers are generic and blame-shifting: "Projects only fail when clients don't follow our process." Or worse: "Our projects don't fail."

The best studio I ever worked with answered: "Based on what you've told me, the biggest risk is that your sales team won't adopt the new system because it adds steps to their workflow. We'd need to either simplify those steps or show clear value that justifies the extra effort. If we can't do either, this project will technically succeed but practically fail."

That's a partner, not a vendor.

Beyond the Questions: Reading Between the Lines

These eight questions are your hiring development studio checklist, but how studios answer matters as much as what they say. Watch for these patterns:

Specificity beats generality. Stories about real projects trump theoretical frameworks every time. If they can't give you concrete examples, they probably don't have them.

Ownership beats deflection. The best studios own their mistakes and learn from them. If every story ends with someone else being at fault, that's how your project will end too.

Clarity beats complexity. Good studios explain technical concepts in plain language. If they're hiding behind jargon, they're either trying to confuse you or they're confused themselves.

Most importantly, trust your gut. If something feels off during these conversations, it probably is. The studios that nail these questions aren't just technically competent — they're battle-tested partners who've learned these lessons the hard way.

At Dazlab.digital, we've been on both sides of these conversations enough times to know that honest answers to hard questions are the foundation of every successful project. Whether you end up working with us or another studio, asking these questions will save you from the expensive education of learning them yourself.

Ready to put these questions to use? Start with the studio you're considering right now. Their answers — or their reluctance to answer — will tell you everything you need to know.

Related Reading

• Evaluating Studio Portfolios
• Red Flags To Watch For