Choosing a software development company is one of the highest-stakes decisions a business makes. Get it right and you gain a partner who ships working software and tells you the truth. Get it wrong and you lose months, tens of thousands of pounds, and — worst of all — confidence that the project can ever work.
These eight tips are a practical vetting checklist: what to look for, what to ask, and the red flags that should make you walk away. Use it whether you're commissioning your first app or replacing a partner that didn't work out.
1. Start with the problem, not the technology
Before you talk to any company, write down — in plain English — what problem the software solves, who uses it, and what success looks like. One page is enough. This document does two jobs: it forces clarity in your own thinking, and it becomes the test of every company you evaluate.
The test is simple: do they engage with your problem, or do they immediately pitch their tech stack? A good partner asks why — why this feature, why now, what happens if it doesn't exist. A bad partner nods and starts quoting. The companies that ask the uncomfortable questions upfront are the ones that won't build you the wrong thing politely.
If you're still deciding what to build versus buy, read our custom vs off-the-shelf guide first — it may save you this entire process.
2. Check their actual work, not their website
Every agency website shows polished case studies. Dig one level deeper:
- Ask for live products. Can you click through something they built? A screenshot portfolio proves they can design; a live product proves they can ship and maintain.
- Ask about projects like yours. Not the same industry necessarily — the same type of complexity. If you need a customer portal with complex permissions, a company that's only built marketing sites is a risk, however impressive those sites are.
- Ask what went wrong. Every real project hits problems. A company that can describe a difficult project, what went wrong, and how they fixed it is telling you the truth. A company that claims everything always goes smoothly is selling.
- Check longevity. Are the products they built two years ago still running and maintained? Software that dies when the project ends tells you about their approach to quality.
3. Meet the people who'll actually build it
The polished partner who sells you the project is rarely the developer who builds it. Before you sign, ask to meet the actual team — the lead developer, the project manager, whoever you'll work with week to week.
What you're assessing: do they understand your business, or just the technical brief? Can they explain technical trade-offs in plain English? Do they push back on bad ideas, or agree with everything? You want a team that challenges you — comfortable agreement in the sales process becomes expensive silence during the build.
Also ask about team stability and size. A company where your project is one of thirty, staffed by whoever's free this week, will not give you their best work. You want to know you're getting a consistent, senior-enough team — not whoever was available.
4. Test with a small paid engagement first
Never commit your full budget to an unproven partner. Structure the engagement so the first step is small, paid, and revealing:
- A discovery phase. Paid analysis producing a scope document, technical approach, and realistic estimate. This tests how they think, how they communicate, and whether their estimate survives contact with detail.
- A pilot milestone. One meaningful slice of the project, built to production quality. This tests how they actually work — code quality, communication rhythm, honesty about problems.
A company that resists a small first engagement — insisting on the full project or nothing — is telling you something. Confident, competent teams welcome the chance to prove themselves. The discovery document also becomes your asset: even if you don't proceed with them, you own a proper specification to take elsewhere.
5. Understand how they work, day to day
Process determines outcome more than talent does. Ask specifically:
- How often will I see working software? The answer should be every one to two weeks — real demos, not status reports. Infrequent demos hide problems; frequent demos surface them while they're cheap to fix.
- Who is my day-to-day contact? You want one accountable person, not a ticket queue. And you want to know what happens when they're on holiday.
- How do you handle changes? Every project changes. You want a clear, fair change process — not "everything is extra" and not "sure, no problem" (which means the cost is hidden somewhere).
- What does testing look like? Automated tests, manual QA, user acceptance testing — ask what they do, not just what they promise. "We test thoroughly" is not an answer; a description of their QA process is.
- How do you estimate? Our guide to web app project estimation covers what honest estimates look like. If their estimate has no ranges, no assumptions, and no contingency, it's a sales document, not an estimate.
6. Get the commercial structure right
The pricing model shapes behaviour. Fixed price, time and materials, and hybrids each suit different projects — and the wrong model for your project creates perverse incentives. Our full comparison in fixed price vs time and materials covers when each wins; the short version is: defined scope and fixed budget means fixed price, evolving product means time and materials.
Beyond the model, check the contract for:
- IP ownership. Under UK law, commissioned software IP doesn't automatically transfer to you. Get explicit IP assignment in writing.
- Payment tied to delivery. Milestone-based payments aligned to working software, not calendar dates. Never pay 100% upfront.
- Exit terms. Notice periods, handover documentation, repository and credential access. A fair contract works if the relationship ends.
- Ongoing support. What happens after launch? Bugs, small changes, and questions need a defined support arrangement — not a vague promise.
7. Check references properly
Ask for two or three client references — and actually call them. Most buyers skip this; it's the highest-value hour in the whole selection process. Ask the references:
- Did the project finish on time and budget? If not, why — and how did the company handle it?
- How did they communicate when things went wrong?
- Did the final product match what was promised?
- Would you hire them again? (The single most revealing question.)
- What do you wish you'd known before starting?
Also do your own diligence: Companies House for financial health, review platforms for patterns (one bad review is noise; five mentioning communication is signal), and LinkedIn for team stability — a company churning through developers will churn through your project.
8. Know the red flags — and walk away
Any one of these is a warning; two or more is a decision:
- Guaranteed timelines with no caveats. "Definitely live in eight weeks" before they've seen a proper spec is a promise they can't keep. Honest companies estimate in ranges.
- No questions about your business. If they don't ask why, they won't build what you need.
- 100% upfront payment. Standard practice is milestone-based. Full upfront payment removes all your leverage.
- No live work to show. Portfolio screenshots without live products, or vague claims about "confidential" work for every project.
- The cheapest quote by far. A quote 40% below the others isn't a bargain — it's a misunderstanding of the scope, a plan to cut quality, or a change-order strategy. See our app development cost guide for realistic UK ranges.
- Unwilling to put things in writing. Verbal promises about scope, timelines, or IP that never make it into the contract don't exist.
- They badmouth every previous client. If every past relationship was the client's fault, you're looking at the common denominator.
- Pressure tactics. "This price is only valid this week" is a sales technique, not a project methodology. Good companies are still there next week.
The bottom line
Choosing a development company is really choosing a working relationship. Prioritise honesty over polish, process over promises, and evidence over claims. Test small, check references, read the contract — and trust the signals. The right partner will welcome your scrutiny; the wrong one will resent it.
If you're evaluating partners for a custom build, we'd welcome the scrutiny — talk to us about your project, and judge us by these same eight tips. Our application development work covers the web apps, portals, and platforms we build for UK businesses.
FAQs
How do I choose a software development company?
Define your problem in writing first, check live products (not just screenshots), meet the actual build team, start with a small paid engagement, understand their day-to-day process, get the commercial model right, call references, and walk away from red flags like guaranteed timelines or 100% upfront payment.
What questions should I ask a software development company?
Ask to see live work, meet the build team, how often you'll see working software, how they handle changes and testing, how they estimate, who owns the IP, what support looks like after launch, and for client references you can call.
What are red flags when hiring developers?
Guaranteed timelines before seeing a spec, no questions about your business, 100% upfront payment, no live work to demonstrate, a quote far below everyone else's, unwillingness to put promises in writing, and pressure tactics on pricing.
Should I choose fixed price or time and materials?
Fixed price suits well-defined projects with fixed budgets; time and materials suits evolving products where you'll stay actively involved. See our full fixed price vs time and materials guide for the detailed comparison.
How much does custom software development cost in the UK?
Meaningful business systems typically run £30,000–£150,000+ to build, plus 15–20% annually for maintenance. Be wary of quotes far below the market range — they usually signal misunderstood scope or planned quality cuts. Our app development cost guide has detailed ranges.
