Buying bespoke software is mostly a trust decision. You can't inspect the quality of code that hasn't been written yet, references are curated, and every portfolio shows the projects that went well. By the time you find out whether you chose wisely, you're months in and the cost of switching is real. Full disclosure before we go any further: we are a vendor. Overclock Minds is a small software development company in Cambridge, and any guide like this written by a vendor will tilt towards the author's strengths. We've tried to compensate the only honest way we know how — for each question, we'll say what a good answer sounds like, what should disqualify a vendor outright, and where the trade-offs genuinely cut against a studio like ours.
Why questions beat portfolios
A portfolio tells you what a company shipped on its best days. It says nothing about how they behave under stress — when an estimate turns out to be wrong, when your requirements shift, when you and they disagree about what "finished" means. Almost any vendor handles the first month of a project well. The differences show up in month four. These twelve questions are designed to surface month-four behaviour while you're still in month zero, when you can still walk away for free.
Ask every vendor the same questions, in writing where you can, and keep the answers. Ambiguity at the sales stage never improves later.
The 12 questions
1. Who will actually write my code?
Plenty of agencies sell with their most senior people and deliver with subcontractors or offshore teams you'll never meet. Subcontracting isn't automatically bad — bringing in a specialist for one gnarly component can be exactly the right call — but undisclosed subcontracting is. Ask for the names and roles of the people who'll do the work, whether they're employees, and whether you can meet them before you sign. A good answer is specific. A disqualifying answer is "our delivery team will handle that" with no names attached.
2. How do you estimate, and when were you last wrong?
Honest estimation produces a range plus the assumptions behind it, not a single confident number. Anyone quoting a fixed price for a vaguely specified project has either padded it heavily or is planning to make their margin on change requests. Ask how they break work down, and — more revealing — ask about a project that ran over and what they did about it. A good answer involves telling the client early and re-planning together. A vendor who claims never to have missed an estimate is not telling you the truth, and that's the bigger problem.
3. What does discovery cost, and what do I walk away with?
A discovery phase should be a small, fixed-price engagement you can buy on its own — typically days to a few weeks of work, priced accordingly. It should produce documents you own and could take to a different vendor: a written scope, an architecture sketch, a prioritised backlog, known risks, and an estimate range for the build. Be wary of free discovery — it's usually a sales call wearing a lanyard — and equally wary of a "discovery" whose only output is a proposal to buy more from the same company.
4. What happens when I change my mind mid-project?
You will change your mind. Everyone does, because building the first version teaches you things you couldn't know up front. Pretending otherwise is the root cause of most vendor disputes. A good answer is a lightweight written process: an impact assessment, what gets deprioritised to make room, the cost and schedule effect, and your sign-off before anything changes. "We're flexible, we'll sort it out as we go" sounds friendly but ends in an argument over an invoice. A change process so heavy that a one-line copy tweak needs a fortnight of paperwork is the opposite failure.
5. Who owns the IP, and when can I see the source?
You should own the intellectual property in the bespoke work once you've paid for it; the vendor may reasonably retain ownership of pre-existing libraries, licensed to you. Just as important: source access from day one, meaning a repository in your organisation's account or with you holding admin rights — not screenshots and demo links. Disqualifiers here are blunt ones. Code withheld until final payment as leverage. A proprietary platform you can't take elsewhere. Any arrangement where you end up licensing back the thing you paid to build.
6. What happens after launch?
Software isn't finished when it ships. Dependencies need updating, security patches need applying, operating systems and browsers change underneath you, and hosting bills arrive monthly. Ask what a typical month of maintenance costs, what's included, and whether the people who built the system are the ones who'll maintain it. No maintenance story at all — "thirty days' warranty, then good luck" — should worry you. So should the opposite: a mandatory, expensive retainer with no exit clause.
7. When did you last turn down work, and why?
A vendor who says yes to everything is either enormous or not being straight with you. Saying no — to a project outside their competence, to a feature that would hurt the product, to a deadline that can't be met — is the clearest sign a company understands its own limits. Ask for a real example and listen for specifics. "We can do anything" is a disqualifier, because nobody can, and you'll discover their actual limits at your expense, on your timeline.
8. Do you understand my domain, or just your stack?
This is the depth-versus-breadth question. Being able to write Python or ship a React app is table stakes; the question is whether the vendor understands regulated data, hardware constraints, clinical workflows, or whatever it is your users actually live with. Deep domain experience isn't always essential — a strong engineer learns fast — but they should be asking sharp questions about your domain in the first meeting, not reciting the same pitch they'd give a logistics firm and a bakery. The local context matters too: the mix of deep tech, life sciences and university spin-outs around here shapes what projects look like, and we've written more about software development in Cambridge specifically.
9. Who do I actually talk to during the build?
In a layered agency, your requirement can pass from account manager to project manager to tech lead to developer — three retellings before anyone writes a line of code, like a game of expensive whispers. Ask whether you can talk directly to the engineers, what the cadence is (weekly demos of working software is a reasonable baseline), and how quickly questions get answered between meetings. A disqualifier: your only contact is a non-technical account manager, and demos happen at "milestones" months apart.
10. What does "done" mean to you?
Get the definition of done in writing. Tested how — automated tests, or someone clicking around once? Deployed where — is there a staging environment you can poke at yourself? Documented for whom? Ask to see redacted acceptance criteria from a real project. A good answer ties "done" to written criteria you sign off against. "Done means the feature works" is not an answer — works on whose machine, under what load, for which users?
11. How many projects do you run in parallel — and what happens when someone's ill?
This question cuts against small studios, ours included, so we'll be straight about it. A small team has limited parallel capacity, and key-person risk is real: if one engineer holds a system entirely in their head and they're off for a month, you have a problem. The honest mitigations are documentation, more than one person knowing each system, and realistic scheduling instead of overcommitting. Large agencies have bench cover, which is a genuine advantage — though the person covering may never have seen your codebase. Either way, a vendor with no answer to this question hasn't thought about it, and that's the disqualifier.
12. If we part ways tomorrow, what do I walk away with?
Ask the exit question while everyone is still friendly. You should walk away with the repository, the deployment configuration, infrastructure running under your own accounts, documentation good enough for a competent new team to take over, and an agreed handover period. Disqualifiers: hosting, domains or app store accounts registered in the vendor's name, or "we'd need to discuss that at the time". Discuss it now. A vendor confident in their work doesn't need to hold your project hostage to keep you.
Small studio or large agency? The honest trade-offs
Neither is better in general; they're better at different jobs.
A large agency can staff six workstreams at once, absorb someone leaving without your project noticing, and produce the paperwork that big-company procurement departments love. The costs: layers between you and the people building, senior staff who rotate off to the next pitch after winning yours, and the quiet risk that a smaller account gets deprioritised when a bigger one shouts.
A small studio offers the inverse. The people you meet are the people who build. The same engineers carry the project from discovery through to maintenance, so context never gets lost in a handover. Your project is a meaningful share of the company's attention rather than a rounding error. The costs are real too: lower parallel capacity, no fifteen-person programmes, and sometimes the honest answer to "can you start Monday?" is "we can start in six weeks".
Match the shape of the vendor to the shape of the project. A multi-workstream programme with a hard regulatory deadline probably needs an agency. A single product where deep understanding, continuity and direct access to engineers matter most is usually better served by a small team.
We're a small studio, and deliberately so. Overclock Minds is AuDHD-founded, and we organised the company around how our minds actually work: hyperfocus means total immersion in one client's problem at a time rather than a tenth of our attention across ten accounts; pattern recognition means spotting the architecture a problem actually needs before code gets written; systems thinking means caring about the whole thing end to end, including long after launch. The flipside is everything in question 11 — we take on a small number of projects at once, and we'd rather tell you our start date honestly than overcommit. There's more on how we work on the about Overclock Minds page.
Take the list with you
Ask all twelve questions, ask every vendor the same ones, and write the answers down — the comparison is more revealing than any single answer. And if you'd like to point the list at us, we'd genuinely welcome it, awkward questions included. Email hello@overclockminds.co.uk or use the contact page. No discovery call required; a plain email describing your problem is a perfectly good place to start.