Table of Contents
- Why the questions to ask a development studio matter more than the price
- What are the nine questions to ask a development studio before signing?
- How do you scope this project, and what happens in the first week?
- Who exactly will build my product, and can I meet them?
- How do you price a build, and what makes the number move?
- How will you help me decide what to build first?
- Can you show me a build like mine, and what happened after launch?
- What happens when the project goes wrong mid-build?
- Who owns the code and the IP when we are done?
- What does post-launch support actually cover?
- Do you understand my business, or just my feature list?
- How to read the answers: telling a builder from a salesperson
- Frequently Asked Questions
- Conclusion: the questions to ask a development studio are the real audition
Quick answer: The questions to ask a development studio before signing are the ones that expose how it scopes, ships, and stands behind the work, and Foundry 5 treats them as an audition rather than a formality. CB Insights found poor product-market fit behind 43% of failed startups, not weak code. Ask what predicts the outcome, before you sign anything.
Three proposals sit in your inbox. Same brief, three numbers that disagree by a factor of five, and a signature line on each that commits six figures and six months of your life. You cannot read the code any of them will write, and you are being asked to trust a stranger with the thing you have staked everything on.
Here is what actually decides it at that stage: the questions to ask a development studio are your only real instrument before money changes hands. Not the portfolio. Not the pitch. The questions, and the way a studio answers them, tell you how it will behave when the project gets hard. And every project gets hard.
This is the founder’s checklist for that conversation. Nine questions, why each one matters, and what a good answer sounds like next to a bad one. No jargon you have to look up: just the calls that separate a studio that ships from a studio that sells.
Why the questions to ask a development studio matter more than the price
The questions to ask a development studio matter more than the price because scope, not day rate, is what empties a budget. Foundry 5 has watched founders pick the smoothest pitch over the studio that pushed back, then pay for that comfort twice. The failure rarely lives in the code. It lives in the brief nobody pressure-tested.
Consider the spread. Four studios quote the same marketplace app and the numbers land at 18,000, 40,000, 85,000, and 160,000 pounds. Same document. That gap is not greed: it is four different readings of a brief that never decided what it was. Every ambiguity you leave open, someone prices in their own favour.
The stakes are heavier than the invoice. According to CB Insights and its analysis of 431 failed startups that shut down since 2023, poor product-market fit sat behind 43% of them: products built competently and wanted by nobody. Picking the wrong studio does not just cost the build fee. It costs the six to twelve months of runway you burn discovering the build was pointed at the wrong thing.
So stop comparing quotes like they measure the same thing. A cheap number often hides a thin scope that will grow the moment you sign. The right studio behaves like a non-technical founder’s tech strategy made real: it interrogates the plan before it prices the work. The nine questions below are how you find that studio before you are locked into a contract with a different one.
What are the nine questions to ask a development studio before signing?
The nine questions to ask a development studio before signing cover scope, team, price, product judgement, track record, failure handling, IP ownership, post-launch support, and business understanding. Foundry 5 uses them as a single audition: ask every studio the same nine, then compare the answers side by side. The gaps between answers tell you more than any portfolio ever will.
Ask them in order, because they build on each other. Scope reveals discipline. Team reveals who actually does the work. Price reveals honesty. The rest reveal whether the studio thinks like a partner or a vendor. Here they are, one at a time, with the answer you want and the answer that should worry you.
How do you scope this project, and what happens in the first week?
A good studio scopes before it quotes, and week one is discovery, not code. Expect workshops, a written scope, and a list of assumptions and risks. The right answer sounds like a plan for reducing uncertainty. The wrong answer is a fixed price handed over before anyone has asked what the product must prove.
This is the single most predictive question you will ask. A studio that starts building in week one is a studio that will discover the hard problems in week eight, when changing them is expensive. Discovery is not overhead you are being upsold. It is the cheapest insurance in the entire project.
Picture two studios. One quotes a flat 60,000 pounds in a day and promises to start Monday. The other spends a paid week mapping your users and your riskiest assumption, then quotes a range and explains what would move it. The first answer flatters your urgency. The second one respects your money.
Watch what they do with a vague requirement. A studio worth signing pushes back on the parts of your brief that are undecided, rather than nodding them through and billing for the confusion later. The best partners treat your scope like architecture: get the load-bearing decisions right first, because everything else rests on them.
Who exactly will build my product, and can I meet them?
Ask for the names of the people who will write your code, and ask to meet them before you sign. The right answer introduces the actual engineers and tells you their seniority. The wrong answer keeps you talking to a salesperson while the build quietly routes to whoever is free, or offshore, without anyone saying so.
The pitch team is rarely the delivery team. Studios win work with their most polished people, then staff the actual project with juniors you never met. That is not always a problem: juniors supervised well ship fine work. It becomes a problem when nobody tells you, and the senior who impressed you disappears after the contract is signed.
So make it concrete. Ask who leads the build, how many other projects they run at the same time, and whether you can talk to them directly rather than through an account manager. A studio proud of its team will introduce them without hesitation. A studio that dodges the question is telling you something before you have signed a thing.
Consider a founder who signed on the strength of a brilliant technical director, then spent four months emailing a project manager who relayed answers from developers she had never been allowed to meet. The code shipped late and thin. The talent existed somewhere in the building. It simply was not on her project.
Already know what you are looking for? Start a conversation with Foundry 5, or keep reading for the rest of the questions before you shortlist anyone.
How do you price a build, and what makes the number move?
Ask whether the price is fixed, time-and-materials, or sprint-based, and ask exactly what triggers a change. The right answer explains the model, shows where the hours go, and names the conditions that move the number. The wrong answer is a single figure with no breakdown, which is a guess wearing the costume of a quote.
Every pricing model is honest if the studio is. Fixed price protects your budget but punishes change. Time-and-materials flexes with reality but needs trust. What matters is not which model they use: it is whether they can explain how scope creep, integrations, or a shifted deadline will hit the total before it happens.
The risk of overrun is not hypothetical. McKinsey and the University of Oxford, studying more than 5,000 IT projects, found that large software efforts ran on average 45% over budget while delivering 56% less value than predicted. A studio that cannot tell you what moves its number is a studio that will discover those overruns with your money.
So press on the edges. Ask what happens if you add a feature in month two, if an integration takes longer than expected, or if you need to pause. The best studios have answered these before and say so plainly. The ones that stiffen at the question are the ones you will argue with later.
How will you help me decide what to build first?
The right studio helps you build less, not more. It should push you toward the smallest version that proves someone wants the product, rather than quoting your entire wish list back at a markup. A studio that agrees to build everything on your list has told you it will not protect you from your own ambition.
This is where a partner earns its fee. Founders arrive with a ten-feature vision and a budget that fits three. The honest answer to who should build your MVP is a studio that helps you cut to the one workflow that matters, ships it, and lets real usage decide the rest. Scope discipline is not a cost saving. It is the strategy.
The mistake is treating a first build as a shrunken version of the whole dream. It is not. It is a complete version of one thing. The best studios will even show you how to validate a startup idea without code where that is possible, because the cheapest feature is the one you proved you did not need to build.
Picture two founders with 50,000 pounds each. One builds a single onboarding flow that saves every user an hour a week and ships in a month. The other spreads the money across five half-features and ships nothing anyone trusts. Same budget. One walks into the next raise with proof, the other with a demo and a shorter runway.
Can you show me a build like mine, and what happened after launch?
Ask for a project close to yours in stage and complexity, then ask what happened to it after launch. The right answer includes outcomes: users, uptime, what shipped next. The wrong answer is a screenshot reel of launch-day designs with no word on whether any of those products still exist.
A portfolio shows what a studio can make look good. It rarely shows what survived contact with real users. When you are evaluating a software development agency, the case studies that matter are the ones with a second chapter: the client who came back, the product that scaled, the metric that moved after the confetti settled.
Demand a reference you can actually call. A confident studio hands you a past client’s number without flinching. A nervous one offers a testimonial it wrote itself. Ask that reference one question above all others: when something went wrong, what did the studio do? That single answer is worth more than the entire portfolio.
Be specific about fit, too. A studio that has shipped ten polished marketing sites may have never carried a real-time payments system or a regulated fintech flow. The best partners tell you honestly when your project sits outside their pattern, rather than stretching a loose analogy to win the work.
What happens when the project goes wrong mid-build?
Ask how the studio handles a missed milestone, a changed requirement, or a disagreement, because every real project meets all three. The right answer describes a process: how they flag slippage early, how they re-plan, who you escalate to. The wrong answer is a promise that nothing ever goes wrong, which means they will hide it when it does.
This question separates the professionals from the optimists. Software is uncertain by nature, and a studio that has shipped real work knows it. What you are testing is not whether they can avoid trouble. It is whether they tell you the moment trouble appears, rather than at the deadline when it is too late to react.
Ask for the mechanics. How often will you see working software, not status decks? What does a weekly update contain? When a feature slips, do you hear about it on Monday or at launch? A studio with real process answers these in the specifics. A studio without one answers in adjectives.
Consider the founder who only learned her project was two months behind at the review meeting where it was meant to launch. The warning signs had been there for weeks, buried in green status reports nobody was allowed to question. Good news travels fast from any studio. Test how fast the bad news travels.
Who owns the code and the IP when we are done?
You want a plain answer: all intellectual property created in the project is assigned to you on payment. In the UK, software is protected by copyright automatically, but commissioned code can legally stay with the studio unless your contract assigns it to you. If a studio is vague here, treat it as the reddest flag on the list.
The UK government is explicit that copyright protects software automatically the moment it is written, yet does not automatically transfer commissioned work to whoever paid for it. That single gap has cost founders their own product. The code ran. The ownership never followed the invoice, and nobody read the contract closely enough to notice.
So get it in writing before the first commit. The clause you want is short and unambiguous: IP assigns to the client on payment, with no lingering licence back to the studio. This is the core of protecting your IP in a software project, and a studio that expects you to own what you paid for will already have it in its standard terms.
Ask about the boundaries too. Who owns the accounts, the repositories, the deployment keys, the data? A studio acting in good faith hands over everything cleanly at the end. One that keeps a quiet grip on your infrastructure has built a dependency you will pay to escape. Clean handover is not a courtesy. It is the mark of a partner.
What does post-launch support actually cover?
Ask exactly what happens after launch, and get the numbers: response times, what counts as a bug fix versus a paid change, and how long support runs. The right answer is a clear support agreement. The wrong answer is the word ongoing with nothing behind it, which means you will negotiate every fix from a position of need.
Launch is not the finish line. It is the moment your product meets reality, and reality finds the bugs your testing missed. A studio that treats support as an afterthought is a studio that will be hard to reach in the week you need it most. The right partner plans for the day after launch before launch day arrives.
Get the distinctions in writing. What is a warranty fix you do not pay for, and what is a new feature you do? How fast do they respond when the product is down versus when it is merely annoying? A vague support promise becomes an expensive surprise the first time something breaks at the wrong hour.
The best studios stay because they want the next phase of your work, not because a clause traps you. Support should feel like a relationship that continues, rather than a handoff dressed up as a partnership. If a studio goes quiet the moment the final invoice clears, you did not hire a partner. You rented one.
Do you understand my business, or just my feature list?
The best studios ask about your customers and your economics before they ask about your features. The right answer shows curiosity about the problem you are solving. The wrong answer takes your feature list as gospel and starts estimating, because a studio that never questions what you asked for cannot protect you from asking for the wrong thing.
A feature list is a symptom, not a strategy. Founders often arrive with solutions already chosen, when what they need is a partner who reopens the problem. A studio that treats itself as an extension of tech strategy for non-technical founders will ask why before it asks how, and that single instinct is what separates a builder from a pair of hands.
Listen for the questions they ask you. A studio thinking about your business asks who pays, what it costs you to serve them, and what has to be true in six months for this to work. A studio thinking only about the build asks for the Figma file. Both can write code. Only one will tell you when the code is a mistake.
This is not about hiring a management consultant. It is about noticing whether the people who will build your product are curious about why it should exist. The studios that ask the uncomfortable business questions early are the ones that save you from the expensive product decisions later. Curiosity before the contract predicts judgement after it.
How to read the answers: telling a builder from a salesperson
Read the answers as a pattern, not a scorecard. A studio worth signing pushes back on your brief, names its team, explains its pricing, and puts IP and support in writing without being chased. A salesperson agrees with everything, quotes fast, and goes soft on the specifics. The tone of the answers is the tell.
Run the nine questions as a single conversation, then notice where each studio got vague. Vagueness clusters around weakness. A studio confident in its process gives specifics on discovery and gets fuzzy on nothing. A studio selling you comfort gets specific on price and vague on everything that would let you hold it accountable.
Evaluate the pushback most of all. The right partner disagrees with you at least once during the first conversation, because a studio that never challenges your plan is quoting your indecision back to you. Comfort is cheap in a sales call and expensive in a build. Friction now is what buys you a product that ships.
Want a second opinion before you sign anything? If you can name the one problem, the one user, and the budget, Foundry 5 will scope your idea in a 30-minute discovery call. Book a free discovery call: no pitch deck, no commitment, just an honest read on whether your project is ready to build.
Frequently Asked Questions
What questions should I ask a software development studio before signing?
Ask the nine questions to ask a development studio that Foundry 5 uses as a signing checklist: how they scope, who builds it, how they price, how they help you decide what to build first, whether they can show a build like yours, what happens when things go wrong, who owns the IP, what support covers, and whether they understand your business. Ask every studio the same nine, then compare the answers.
How do you know if a development studio is any good?
You know a development studio is good by how it answers hard questions, not how it pitches. A strong studio scopes before it quotes, introduces the actual engineers, explains what moves its price, and puts IP and support terms in writing. The tell is pushback: a studio that challenges your brief in the first call is protecting the project, not resisting it.
Who owns the code when you hire a development studio in the UK?
In the UK, the studio can legally own the code it writes unless your contract assigns the IP to you. Software gets automatic copyright on creation, but commissioned work is not automatically transferred to whoever paid for it. Insist on a written clause assigning all intellectual property to you on payment, agreed before any code is written.
Should a startup hire a development studio or a freelancer?
Hire a freelancer when the project is small, simple, or already proven, and a development studio when you need discovery, a team, and continuity after launch. A freelancer gives you one skill set and a single point of failure. A studio gives you scoping, several disciplines, and someone still reachable when the product breaks six months later.
How much does it cost to build an MVP with a development studio in the UK?
The cost of an MVP tracks scope, not day rate, so the honest answer is a range that a studio should narrow during discovery. A focused build around one core workflow costs far less than a feature-complete platform. Foundry 5 scopes MVPs into a fixed four-week sprint precisely so the number is tied to what the product must prove, not to an open-ended wish list.
Conclusion: the questions to ask a development studio are the real audition
The questions to ask a development studio were never about catching anyone out. Foundry 5 treats them as an audition: nine prompts that reveal whether a studio scopes with discipline, staffs with honesty, prices with clarity, and stays after launch. The answers tell you who you are actually hiring, long before the first line of code.
Do the asking before the signing. Run the same nine questions past every studio on your shortlist, then compare the answers rather than the quotes. The cheapest number in your inbox is often the thinnest scope, and the smoothest pitch is often the one with the least behind it.
If you are a founder weighing your first build and want a partner who will argue with you before it invoices you, book a free 30-minute discovery call with Foundry 5. No pitch deck. No pressure. Just a straight answer on whether your project is ready to build.
Ask first. Sign second.
