Choosing a software development company is a decision you live with for years — and the sales deck is the least reliable input you have. The reliable inputs are verifiable: reviews from named clients, case studies with numbers, certifications you can look up, and contract clauses you can read. Here is the 12-point checklist we would use ourselves, plus the red flags that should end a conversation.
The 12 points
1. Verified client reviews — recent ones
Look for reviews on platforms that verify the reviewer (Clutch interviews clients directly). Volume matters less than recency: five reviews from the last year beat twenty from five years ago. Ask yourself: would these clients be reachable if you asked for a reference call?
2. Case studies with measurable results
A logo wall is not evidence. A case study that says who the client was, what the problem cost them, what was built and what changed — in numbers — is. If every case study is anonymous and metric-free, assume there is a reason.
3. Who actually writes your code
Ask about the seniority of the people assigned to your project, not the company average. A senior-led pitch followed by a junior-heavy delivery team is the oldest trick in the industry. Ask directly: how many years of experience will the engineers on my project have?
4. Security you can verify
GDPR compliance is claimed by everyone; an ISO 27001 certificate has a number and an issuing body you can check. For anything touching personal or financial data, treat certified security practices as a requirement, not a bonus.
5. Code and account ownership — in the contract
On final payment, the source code, store accounts, cloud infrastructure and domain must be yours, with an explicit IP-assignment clause. If a vendor hesitates on this, everything else is irrelevant.
6. A transparent pricing model
Fixed price for well-defined scope, time-and-materials for iterative work — both are legitimate. What is not legitimate is an open-ended budget. Insist on a milestone plan where you see cost against progress.
7. Visible progress, weekly
Working software every week — demos, TestFlight builds, staging links — not status reports. If the first working build arrives in month three, you have no way to steer.
8. Technology recommendations with reasoning
A good partner justifies the stack against your product: when native mobile is worth the cost, when cross-platform saves you 40–60%, why this database. A vendor who prescribes the same stack to every client is optimising for their convenience, not your product.
9. A clear communication structure
Know who answers you and how fast. A defined contact — in our case a specialist consultant — and a stated response time beat a generic inbox. Slow answers during the sales phase never get faster after signing.
10. Post-launch support in writing
iOS and Android releases, dependency updates, security patches: software needs maintenance. Ask what happens after launch — SLA, retainer or sprint-based evolution — before you sign, not after the first breakage.
11. Time zone and working overlap
For EU companies, a nearshore team in Romania shares your working day; for US teams, the morning overlap covers standups and decisions. Measure the real overlap in hours — collaboration quality follows it.
12. Their own products and engineering culture
Teams that run their own products understand uptime, onboarding and support from the owner's side. Ask what the company builds for itself, and read their engineering blog — it shows how they think when nobody is selling.
Red flags that should end the conversation
- Estimates without questions — a serious team cannot price what it has not understood
- No IP-assignment clause, or hosting/accounts that stay in the vendor's name
- “Yes” to every request without trade-offs — you are not talking to engineers
- Anonymous portfolio, no verifiable reviews, no named team
- Pressure to sign before a written scope exists
Run any shortlist through these 12 points and the field usually narrows itself. And test us against the same list — our reviews, case studies with numbers, certificate ID and contract terms are public or available on request. That is the point of the checklist: it works on everyone, including us.
