Software development company pitches converge alarmingly fast. By the third meeting, every supplier on your shortlist has shown a case study with a recognisable logo, described their process as agile, promised a dedicated senior team and quoted a figure that sits within twenty per cent of everyone else’s. The differences that will actually decide whether your project ships are not in the deck. They surface only when you ask specific, uncomfortable, verifiable questions — and when you watch how quickly the temperature in the room changes as you ask them.
Most procurement failures in this market are not the result of hiring an incompetent supplier. They come from hiring a software development company that was genuinely good at something other than the thing you needed: a team that builds beautiful consumer apps taking on a regulated integration project, or a delivery shop with excellent engineers and no product discipline being handed an unspecified idea. The mismatch is visible before contract signature if you know what to probe, and almost invisible afterwards until the money is spent.
This guide gives you thirty questions to put to any software development company, grouped into the seven areas where engagements actually break down, along with what a strong answer sounds like and what should worry you. It pairs with our guide to writing a software development RFP if you are still assembling a shortlist, and with the software development contract checklist for the clauses these answers should eventually end up in.
Table of contents
- What You Are Really Buying From a Software Development Company
- Questions 1-5: Team, Skills and Who Writes Your Code
- Questions 6-10: Process, Delivery Rhythm and Real Evidence
- Questions 11-15: Price, Contracts and Change Control
- Questions 16-19: Code Ownership, IP and Exit Rights
- Questions 20-23: Security, Data Protection and Compliance
- Questions 24-27: Support, Warranty and Life After Launch
- Questions 28-30: References, Finances and Cultural Fit
- How to Score Software Development Company Answers Objectively
- Red Flags That Should End a Software Development Company Shortlist
- Software Development Company Questions: FAQs
- References
What You Are Really Buying From a Software Development Company
The word “supplier” misleads people here. You are not buying a finished product from a catalogue; you are buying a team’s judgement, applied to a problem neither side fully understands yet, over a period long enough for both organisations to change. That is closer to hiring a department than to purchasing equipment, and it explains why price comparison alone predicts outcomes so poorly.
Capability is not the same as capacity
Plenty of firms have engineers available. Far fewer have engineers who have solved your particular shape of problem — high-volume transactions, offline-first mobile, legacy integration, strict audit trails. A software development company with genuine domain experience will describe the second-order problems before you mention them. One with capacity but not capability will agree enthusiastically with everything you say, because it has no prior scar tissue to disagree with.
The engagement model changes the incentives
How you buy shapes what you get. A fixed-price arrangement rewards tight scope control and punishes discovery; time and materials rewards transparency and punishes nothing at all unless governance is strong. Our comparison of fixed price versus time and materials covers the mechanics, but the question to hold in mind through every meeting is simple: under this model, what behaviour is my software development company being paid to exhibit?
Size, structure and where you sit in the queue
A small agency will give you their best people because they only have best people; they will also struggle if two clients escalate in the same week. A large software development company has depth, process and someone to call at midnight, but your project may be staffed from whoever finished last month. Neither is wrong. What matters is knowing which one you are buying and pricing the trade-off honestly.
Match the type of firm to the shape of the work
Before the meetings start, decide which category of software development company you are actually shopping for, because the questions land differently in each. Rate bands in the UK market vary by a factor of five, and the cheapest hour is rarely the cheapest outcome once specification overhead and rework are counted.
| Supplier type | Typical UK day rate | Best suited to | Main risk to manage |
|---|---|---|---|
| Freelance contractor | £350-£650 | Small, well-specified builds | Single point of failure |
| Boutique agency (5-25 staff) | £500-£850 | Products needing design and build | Capacity under simultaneous demand |
| Mid-market firm (25-150 staff) | £650-£1,100 | Multi-team, integrated systems | Team quality varies by pod |
| Enterprise consultancy | £1,100-£1,800 | Regulated, large-scale programmes | Cost of process overhead |
| Offshore delivery centre | £180-£400 | Well-specified, stable scope | Specification and timezone overhead |
| Hybrid onshore lead + offshore build | £400-£700 | Cost-sensitive longer programmes | Handover quality between tiers |
Questions 1-5: Team, Skills and Who Writes Your Code
The single most common gap between pitch and delivery is personnel. The people who impress you in the sales meeting are frequently not the people who open your repository. Every question in this group exists to close that gap before it opens.
1. Who exactly will be on my team, and can I meet them?
Ask for names, roles, seniority and the percentage of each person’s week your project gets. A confident software development company will bring the proposed technical lead to the second meeting without being asked twice. Vagueness here — “we’ll allocate from the pool at kick-off” — is the clearest early warning available to you, and it costs nothing to test.
2. What proportion of the team are permanent employees?
Subcontracting is normal and not automatically a problem, but you should know. A software development company that is sixty per cent contractors sourced per project carries different continuity risk from one whose permanent staff have worked together for three years. Ask what happens to your delivery if a subcontractor’s rate is outbid mid-engagement.
3. How long has this team worked together?
Team tenure predicts throughput better than individual CVs. Groups that have shipped together already have shared conventions, a working review culture and realistic estimates. A software development company assembling five strong strangers for your project is starting from a lower velocity than the proposal implies, and the ramp usually takes six to eight weeks.
4. What happens when someone leaves mid-project?
You want to hear about pairing, documented decisions, shared repository access and a bus factor above one. What you do not want is a named hero whose absence would stall you. Ask the software development company directly how many of its people could deploy your system to production unaided at the end of month three.
5. Who owns the technical decisions — you or us?
Both extremes fail. A supplier who defers every architectural choice to a client without engineering leadership is abdicating; a software development company that refuses to explain its choices is building something you cannot maintain. The healthy answer describes a decision record, a named technical authority, and an escalation route when you disagree.
Questions 6-10: Process, Delivery Rhythm and Real Evidence
Everyone says agile. The word has been sanded smooth by fifteen years of marketing use, so stop asking whether a supplier is agile and start asking for observable delivery mechanics. The Scrum Guide and the GOV.UK Service Manual both describe practices you can verify rather than adjectives you cannot.
6. How often will working software be in my hands?
The only honest measure of progress is software you can use. A strong software development company commits to a demonstrable increment every two weeks from an early date, in an environment you can access yourself. If the first usable build is scheduled for month five, you are buying a plan rather than a product, and you will not discover problems until they are expensive.
7. What is your deployment frequency and lead time for change?
These are two of the four delivery metrics from the DORA research programme, and mature teams know their numbers. Weekly or better deployment on a comparable client project indicates real automation. A software development company that answers “we deploy at the end of each phase” is describing a manual pipeline that will absorb a slice of your budget in release overhead.
8. Show me your definition of done
Ask to see the actual written definition used on a current project. It should include automated tests, code review, deployment to a shared environment and acceptance by someone other than the developer. A definition of done that stops at “developer says complete” is why status reports on troubled projects stay green until the week before launch.
9. What does your testing actually cover?
Push past “we do automated testing” into specifics: unit coverage on business logic, integration tests across service boundaries, and whether the pipeline blocks a merge when tests fail. A software development company that cannot tell you what percentage of its test suite runs on every commit is telling you the suite is decorative.
10. How do you handle discovery before the build?
Any software development company that quotes a firm price and date from a two-page brief is guessing, and you will pay for the guess through change requests. The professional answer is a paid, time-boxed software discovery phase producing a scoped backlog, technical approach and a defensible estimate range before anyone commits to a delivery date.
Questions 11-15: Price, Contracts and Change Control
Commercial questions get asked late and superficially, usually reduced to comparing headline totals. That comparison is close to meaningless without knowing what each number includes, what triggers a change request, and who absorbs the cost of a wrong estimate.
11. What is included in this figure, and what is explicitly excluded?
Ask for the exclusions in writing. Common omissions are third-party licences, cloud hosting, design revisions beyond a set number, data migration, user acceptance testing support and post-launch fixes. A software development company that produces a clear exclusions list is easier to work with than one whose proposal appears to cover everything and quietly does not.
12. How do you handle change, and what does it cost?
Every project changes. The question is whether change is a managed process with a written estimate and a decision point, or an invoice that appears after the fact. Ask the software development company to show you a real change request from another engagement with the client details removed. The format tells you more than any contractual clause about how the relationship will feel.
13. What is your estimate confidence, and what drives the range?
Good estimators talk in ranges and name their assumptions. If you are given a single number with two significant figures for nine months of work, that number is a negotiating position rather than a forecast. Compare the shape of the answer against typical custom software development cost bands before deciding whether it is credible.
14. What are the payment milestones tied to?
Milestones tied to dates reward the passage of time. Milestones tied to demonstrable, accepted functionality reward delivery. Push for the latter, with a meaningful proportion of value held until acceptance. A software development company confident in its delivery will accept outcome-linked milestones; one that resists them is telling you about its own internal cash pressure.
15. What happens if we are late — and what if you are?
Ask about both directions. Client-side delays in feedback, data or access are the most common cause of slipped dates, and a mature software development company will have a written mechanism for flagging them early rather than banking them as a defence. Equally, ask what remedy exists if their delivery slips: re-planning, credit, additional capacity at their cost, or nothing at all.
| Question area | A strong answer sounds like | A warning sign sounds like |
|---|---|---|
| Named team | “Here are the four people, with CVs and availability” | “We allocate from the pool at kick-off” |
| Delivery cadence | “You get a usable build every two weeks from week four” | “First demo is at the end of phase two” |
| Estimating | “£240k-£310k, driven by these three unknowns” | “£275,000” with no range and no assumptions |
| Change control | “Written estimate, you approve before we build” | “We’ll be flexible, don’t worry about it” |
| Code ownership | “Assigned to you on payment, in your repository” | “You get a perpetual licence to use it” |
| Security | “Cyber Essentials Plus, and here is our last pen test” | “Our developers are very security-conscious” |
| Exit | “Thirty days’ assisted handover at agreed rates” | “Nobody has ever needed to leave” |
| References | “Speak to these two, including one that went badly” | “We can’t share clients for confidentiality reasons” |
Questions 16-19: Code Ownership, IP and Exit Rights
This is the group most often skipped, and the one that costs the most when it is wrong. Under UK law the default position on commissioned work is not what most buyers assume: absent a written assignment, the developer generally retains copyright in the code they author, as the government’s guidance on ownership of copyright works sets out.
16. Who owns the code, and when does ownership transfer?
You want written assignment of copyright, effective on payment, covering all deliverables. “You have a licence to use it” is a materially different and much weaker position. Read our detailed treatment of source code ownership before you accept any wording, because retrofitting an assignment after a relationship sours is expensive and sometimes impossible.
17. What parts of the delivered system are not mine?
Almost every build contains third-party components, open-source libraries and sometimes the supplier’s own reusable framework. That is fine and normal, but it must be disclosed. Ask the software development company for a written inventory of components and licences, and check whether any copyleft obligations affect how you can distribute or commercialise the result.
18. Where does the code live during the project?
The repository should sit in your organisation’s account with the software development company granted access, not the other way round. The same applies to cloud infrastructure, domain registrations and CI pipelines. This single arrangement removes most of the leverage a difficult exit would otherwise involve, and no reasonable supplier objects to it.
19. What does an exit look like in practice?
Ask for the exit assistance clause and read it. It should specify a notice period, a defined handover package — documentation, credentials, architecture notes, deployment runbook — and a rate for transition support. A software development company that has handled exits professionally will describe the process calmly. Those who bristle at the question are describing their instinct rather than their contract.
| Contract clause | What you should hold out for | The weak version to reject |
|---|---|---|
| IP assignment | Copyright assigned on payment of each invoice | Assignment only on final project sign-off |
| Third-party components | Written inventory with licence terms | Silence, or “standard open-source libraries” |
| Repository control | Client-owned account, supplier invited | Supplier account, code delivered at the end |
| Exit assistance | 30-60 days at agreed rates, defined package | “Reasonable assistance” with no definition |
| Warranty | 90 days of defect fixes at no charge | 30 days, or defects billed as support |
| Key personnel | Named leads, replacement subject to approval | “Equivalent resources at our discretion” |
| Data processing | UK GDPR processor terms, named sub-processors | A generic confidentiality clause only |
| Acceptance | Written criteria agreed before each increment | Deemed acceptance after a set number of days |
Questions 20-23: Security, Data Protection and Compliance
Security answers are easy to fake in a meeting because the vocabulary is public. Ask for evidence with a date on it. A software development company handling personal data on your behalf is a processor under UK GDPR, and your organisation remains accountable for how they handle it.
20. What security certifications do you hold, and when were they last audited?
Cyber Essentials is the realistic baseline for UK suppliers, and Cyber Essentials Plus involves independent verification. Certification is not proof of secure code, but the absence of any external assessment tells you nobody outside the software development company has ever looked. Ask for the certificate and check the expiry date rather than accepting the logo on the website.
21. How do you handle our data during development?
Production data in development environments is one of the most common causes of avoidable breaches. Ask what data the team will hold, where it will be processed, how it is anonymised for testing and how long it is retained. The ICO’s data protection principles are the standard your contract terms should map onto.
22. What is your secure development practice?
Look for dependency scanning, secrets management, code review with a security lens and a documented process for patching vulnerable libraries. The OWASP Application Security Verification Standard gives you a vocabulary for this conversation and a level to specify in the contract with your software development company.
23. Will you support an independent penetration test?
The answer should be yes, with a remediation window agreed in advance and clarity on who pays for fixing what. A software development company that treats external testing as an insult is one whose code has not been tested externally. Budget for one test before launch and one annually thereafter.
Questions 24-27: Support, Warranty and Life After Launch
Launch is the middle of the project, not the end. A system nobody has agreed to maintain degrades quickly, and the arrangements are far cheaper to negotiate while the software development company still wants your signature.
24. What warranty covers defects after go-live?
Ninety days is a common baseline, and it should cover defects against agreed acceptance criteria at no charge. Clarify the boundary between a defect and a change, because that boundary is where most post-launch disputes live. A software development company with a clear written definition of the two has thought about it before you asked.
25. What does ongoing support cost, and what does it include?
Get the support proposal at the same time as the build proposal, not afterwards. Response times, resolution targets, hours of cover and the escalation path all belong in writing. Expect ongoing software maintenance cost to run between fifteen and twenty-five per cent of the original build cost each year.
26. Who keeps dependencies current?
Frameworks, runtimes and libraries all reach end of life on schedules nobody controls. Ask whether patching sits inside the support fee or is billed separately, and how the software development company prioritises upgrade work. A system left unpatched for two years becomes a security liability and an expensive technical debt audit waiting to happen.
27. Can my own team take over the code?
Even if you never intend to, the answer reveals a lot. It should involve readable documentation, conventional technology choices and a software development company willing to run a structured handover. If taking the system in-house would require a rewrite, you are locked in — and the price of everything you buy afterwards quietly reflects it.
Questions 28-30: References, Finances and Cultural Fit
The last three questions are about verification. Everything above can be answered impressively by a supplier who has practised. These are considerably harder to rehearse.
28. Can I speak to a client whose project went badly?
This is the single most revealing question on the list. Every experienced software development company has had a difficult engagement. The ones worth hiring will tell you about it, explain what they changed afterwards, and sometimes put you in touch. A spotless twenty-year record means either very selective disclosure or very little experience.
29. What is your financial position?
For any engagement of meaningful size, check the filed accounts of the software development company at Companies House. You are looking for signs of stability rather than profitability: shrinking net assets, late filings or repeated director changes all matter when you are about to depend on a firm for eighteen months.
30. How do you handle disagreement?
Ask for a specific example of a time they told a client something the client did not want to hear. A software development company that cannot produce one either avoids conflict or does not remember it, and both are problems. The engagements that go well are the ones where a supplier says “that will not work, here is why” in month two rather than month ten.
How to Score Software Development Company Answers Objectively
Thirty questions produce a lot of qualitative material, and human memory flatters whoever presented last. Score the answers as you collect them, using weights agreed before the first meeting so the process cannot be reverse-engineered to justify a preference formed in the room.
Weight the things that predict outcomes
Headline price is the least predictive input available and it dominates most decisions anyway. Put the weight where the evidence is: relevant experience, named team, verifiable delivery mechanics and commercial protection. When two suppliers score within five per cent of each other, treat the difference as noise and choose the software development company with the stronger team.
Score evidence, not eloquence
Give the highest marks to answers that come with an artefact — a redacted change request, a real definition of done, a certificate with a date, a reference who takes your call. A software development company that can only describe its practices in the abstract may still be excellent, but you have no way to know, and you are being asked to pay for the assumption.
Run the same script with every supplier
Ask each software development company the identical thirty questions in the same order, ideally with the same people in the room. Variation in your process produces variation in your data. Where an answer is unclear, ask the follow-up immediately rather than noting it for later, because the follow-up is usually where the real position emerges.
Red Flags That Should End a Software Development Company Shortlist
Some answers are not merely weak; they are disqualifying. Recognising them early saves weeks of evaluation and, occasionally, an entire year of delivery.
The pitch team disappears after signature
If the people presenting cannot commit to being on the project, you are watching a sales function rather than meeting a delivery team. Insist that the proposed technical lead attends before you shortlist a software development company, and make named continuity a contractual term rather than a hopeful expectation.
No willingness to be measured
A supplier who cannot or will not quote deployment frequency, defect rates, or a definition of done is not measuring its own delivery. You will inherit that absence of measurement, and the first time you notice will be when a date slips without warning. This is the pattern that most reliably precedes needing to rescue a failing project.
Certainty without discovery
A firm price and a firm date offered from a short brief is not confidence; it is either inexperience or a deliberate strategy to win on price and recover through change requests. Any software development company that has delivered at scale knows the range of outcomes a vague brief permits, and will say so plainly.
Ownership or exit terms that are non-negotiable
Standard terms are reasonable. Refusal to discuss code assignment, repository location or exit assistance is not, because those clauses only matter when the relationship fails, which is precisely when you will have no leverage to negotiate them. Walk away rather than accept a promise to sort it out later.
Software Development Company Questions: FAQs
How many suppliers should I put on a shortlist?
Three is the practical optimum for most projects. Two gives you no real comparison, and five turns evaluation into a full-time job while giving each software development company too little of your attention to produce a considered proposal. Run the same thirty questions across all three and score as you go.
Should I always choose the cheapest proposal?
Almost never, and the gap is rarely what it appears. A lower figure often reflects a narrower reading of scope, a more junior team or exclusions that will return as change requests. Normalise the proposals against an identical scope statement first, and only then compare. Price should be one input among several, not the tie-breaker.
Is it safer to hire a local software development company?
Proximity helps with discovery, workshops and stakeholder access, and it removes timezone friction from decision-making. It is not a substitute for capability. If you are weighing local delivery, our software development company in Chester page sets out what an onshore engagement typically involves. Distributed teams work well when the written communication discipline is strong.
How long should the selection process take?
Four to eight weeks from brief to signature is realistic for a mid-sized build. Faster than that usually means the questions above were skipped; much slower and the software development company you wanted has reallocated the team. Book the meetings in a tight sequence so your comparisons stay fresh.
What if the supplier will not answer some of these questions?
Note which ones. A software development company may decline on genuine confidentiality grounds and offer an alternative form of evidence, which is reasonable. One that deflects on team composition, code ownership or delivery metrics is protecting information you need, and the pattern of what they avoid is itself a useful signal.
Do these questions change for a small project?
The list compresses but the categories do not. On a short build you might merge the process and testing questions and skip the financial check, but ownership, exit and named-team questions matter at every size. A realistic software development timeline and a clear definition of done are worth as much on a six-week project as a six-month one.
Should I pay for a discovery phase before committing?
Yes, for anything beyond a trivial build. A paid discovery costs a small fraction of the project and produces a scoped backlog, a technical approach and an estimate you can hold someone to. It also gives you a low-risk trial of the working relationship with the software development company before the large commitment, which is frequently the more valuable outcome.
References
GOV.UK Service Manual: Agile delivery
NCSC: Cyber Essentials overview
ICO: A guide to the data protection principles
GOV.UK: Ownership of copyright works
GOV.UK: Intellectual property, an overview
OWASP Application Security Verification Standard
DORA: DevOps Research and Assessment
Association for Project Management: What is Project Management?
