Why This Matters
Most buyers of software development services are not developers. They're founders, operations directors, heads of product — people who know their business problem clearly but may not know enough about software development to evaluate a supplier properly.
That information gap is where bad engagements begin. You can't evaluate a development company purely on their website, their portfolio, or how well they present. You need to ask the right questions and know what good answers look like.
Here are the 20 questions worth asking before you sign anything.
Process and Delivery
1. What does your delivery process look like end-to-end?
What a good answer sounds like: A clear description of phases — typically discovery, design, build, test, launch — with a rough sense of what happens at each stage and who's involved. They should be able to explain this in plain English.
Red flag: Vague or jargon-heavy responses. If they can't explain their process clearly before the engagement, they won't communicate clearly during it.
2. How do you handle requirements gathering?
What a good answer sounds like: A structured discovery phase involving workshops, user research, or detailed requirement sessions. They should want to understand your business problem before writing a line of code.
Red flag: They jump straight to quoting or ask you to write a specification before any conversation. Requirements gathering is a collaborative process — companies that skip it are setting you up for a mismatch.
3. How often will I see working software?
What a good answer sounds like: At least every two weeks. Regular demos of working software are the only reliable way to catch misalignment early.
Red flag: "We'll demo at the end of each phase." Phases can stretch to months. You should be seeing progress regularly, not waiting for a big reveal.
4. What does your testing process look like?
What a good answer sounds like: A combination of automated testing (unit tests, integration tests) built throughout development, plus manual QA. Testing should be continuous, not something bolted on at the end.
Red flag: "We test before we hand over." That's too late. Bugs found post-launch cost 10–100x more to fix than bugs caught during development.
5. How do you manage scope changes?
What a good answer sounds like: A defined change request process — new requirements are logged, estimated, and agreed in writing before work starts. The trade-off between scope, time, and budget is made explicit.
Red flag: "We'll handle it as we go." Without a formal process, scope creep is almost guaranteed, and you'll either run out of budget or get a watered-down product.
Team and People
6. Who will actually be working on my project?
What a good answer sounds like: Named individuals or at least a clear description of seniority and role. You should know whether you're getting a senior developer, a mid-level developer, or a team of both.
Red flag: "Our team of experts." That tells you nothing. Ask to meet the people who will do the work, not just the salesperson.
7. Will my project be subcontracted?
What a good answer sounds like: Either "no, entirely in-house" or a clear, transparent description of what is and isn't subcontracted. Subcontracting isn't necessarily bad — agencies often use trusted specialists — but you should know about it.
Red flag: Evasiveness or denial when their day rate implies they're not UK-based in-house staff. If something doesn't add up, push harder.
8. What happens if a key developer leaves mid-project?
What a good answer sounds like: A description of how knowledge is documented and shared, and how they'd manage a transition. Good teams use code documentation, handover processes, and shared repositories that aren't locked in someone's head.
Red flag: "That won't happen" or no clear answer. People leave. The answer to this question tells you how professionally they run their operations.
9. Who is my day-to-day point of contact?
What a good answer sounds like: A named project manager or lead developer who is responsible for communication and is available to you on a regular basis.
Red flag: "The whole team is your point of contact." Diffuse responsibility means slow responses and inconsistent communication.
Commercial and Legal
10. Who owns the intellectual property once the project is complete?
What a good answer sounds like: "You own all code and assets on final payment" — or a clearly explained arrangement where you have a perpetual licence and understand any constraints.
Red flag: Ambiguity or "we retain ownership of our frameworks." Frameworks can be a legitimate carve-out, but you need clarity on exactly what you own and what you don't before you sign.
11. What is your pricing model and how do you handle overruns?
What a good answer sounds like: A clear explanation of whether they work fixed-price, time-and-materials, or a hybrid — and what happens if the estimate is exceeded and why. There are no universally right or wrong models, but you need to understand the model and the risk allocation.
Red flag: Guaranteed fixed-price quotes provided within days of first contact, without discovery. Fixed-price without proper scoping just means the risk is hidden in padding or passed back to you via change requests.
12. Can I see a sample contract before we get into detailed scoping?
What a good answer sounds like: Yes, they'll share a standard contract template early. You can see how they handle IP, payment terms, termination, liability, and warranties.
Red flag: Resistance to sharing contract terms before you're committed. You need to know what you're signing.
13. What are your payment terms?
What a good answer sounds like: Milestone-based payments tied to delivery of working software, or regular monthly billing. A reasonable upfront deposit (20–30%) is normal.
Red flag: Large upfront payments (50%+) before any work is done, or payment terms that have no link to delivery.
Communication and Support
14. How will we communicate day to day?
What a good answer sounds like: A clear description of tools (Slack, email, project management platform) and expected response times during working hours.
Red flag: "However you prefer." The supplier should have a defined communication framework that they know works. Flexibility is fine; no process is not.
15. What does your project management look like?
What a good answer sounds like: A project management tool you'll have access to (Jira, Linear, Notion, Trello — any of them), with visibility into progress, backlog, and upcoming work.
Red flag: "We manage it internally, we'll update you weekly." You should have direct visibility, not be reliant on weekly summaries.
16. What support do you provide after launch?
What a good answer sounds like: A clearly described post-launch support period (typically 30–90 days), what's covered (bug fixes vs. new features), and options for ongoing maintenance.
Red flag: Silence on post-launch. Launch is not the end. You will have bugs. You will need changes. Know what you're getting.
Track Record
17. Can you provide references from similar projects?
What a good answer sounds like: Yes, and they'll provide two or three relevant clients you can contact directly.
Red flag: Vague testimonials on a website but resistance to providing direct references. Case studies are marketing; references are evidence.
18. What's the most difficult project you've delivered, and what made it difficult?
What a good answer sounds like: A candid story that includes what went wrong and how they handled it. Every experienced team has a war story. The question is whether they're honest about it and what they learned.
Red flag: "All our projects run smoothly." Either they're lying, or they haven't done anything challenging enough to be worth your attention.
If Things Go Wrong
19. What happens if we're unhappy with the quality of work?
What a good answer sounds like: A clear quality standard in the contract and a defined remediation process — they fix issues at their cost within an agreed timeframe.
Red flag: "We're confident in our quality." That's not an answer. Understand in advance what your options are if quality falls short.
20. What's the exit process if we need to part ways?
What a good answer sounds like: Clear IP transfer terms on leaving, code in a repository you own, documentation that enables a new team to continue, and reasonable notice periods.
Red flag: Lock-in through proprietary tooling, repositories held by the supplier, or contracts with punitive exit clauses. You should always be able to leave.
Questions Specific to AI-Enabled Development
If you're working on a product that involves AI features — or if the supplier is using AI tools to accelerate their own development process — add these:
"Do you use AI coding assistants, and how do you quality-control AI-generated code?" A good answer acknowledges use and describes review processes. AI-generated code needs the same review and testing rigour as human-written code — the risk is teams that treat it as automatically correct.
"Who owns the AI model or service used in my product?" If they're building AI features using a third-party model (OpenAI, Anthropic, Google), you need to understand the licensing, data handling, and what happens if that provider changes pricing or terms.
"How do you handle hallucinations and AI output errors in production systems?" For any system where AI output is user-facing or affects decisions, there needs to be a validation and fallback strategy. This question separates teams who've thought it through from those who've bolted an API on.
A Final Note
These questions aren't designed to catch suppliers out. They're designed to start an honest conversation. A good development partner will welcome them. They'll answer clearly, push back where they disagree, and use the discussion to understand your project better.
If a supplier becomes defensive, vague, or dismissive when you ask reasonable questions — that's the most useful answer of all.
Need help with your project? Get in touch — we respond within 24 hours.