Blog
Key takeaways:
Most guides on this subject hand you a checklist and wish you luck. The trouble with a checklist is that every firm passes it. They all have a portfolio, they all say communication matters, and they all have five-star reviews on a directory somewhere. You finish the calls with a folder of PDFs and a gut feeling, which is exactly the state you were in before you started.
What actually separates a good outcome from an expensive one is a decision instrument: a small set of criteria you weight before you talk to anyone, twelve questions that make the differences visible, and a handful of contract terms that determine what happens when the project deviates from the plan. That last part matters most, because it always deviates.
This is a working framework for how to choose a software development company, built to be used rather than admired. It ends with the terms worth arguing over and the signals worth walking away from.
One framing note before it starts. Knowing how to choose the right software development company is not the same as finding the best one in the abstract, because the best firm for a regulated data platform is rarely the best firm for a consumer app. You are matching a firm to a job, and the job has to be described first.
The failure mode people expect is a firm that cannot code. That is rare. The common failure is subtler: a competent team builds precisely what was asked for, the thing does not fit the business, and nobody had the standing to say so in month two.
The cost shows up in three places. There is the money already spent, which is usually recoverable only as a lesson. There is the time, which is the expensive part, because a nine-month build that lands wrong costs you the market position you were building toward. And there is the codebase itself, which the next team has to either inherit or discard, and inheriting a system built without documentation or tests frequently costs more than starting again.
None of that is visible during a sales process. All of it is predictable from the answers to a dozen questions, if you know which ones to ask and what a weak answer sounds like. That is the whole of how to choose a software development company reliably: asking things whose answers cannot be improvised.
We have been on both sides of this. Some of our best engagements started as rescues, and the pattern in the ones we take over is consistent: the original selection was made on price and portfolio, and nobody asked how scope changes would be priced until the first one arrived. That holds as much for a staff-augmentation arrangement as for a fixed-scope build, and the differences between those outsourcing models decide who absorbs the cost when scope moves.
The step that changes the outcome most happens before any firm hears from you, and almost nobody takes it.
The Government Accountability Office interviewed executives and managers at leading commercial organizations about how they acquire IT services, and published the resulting framework in November 2001, in a report whose sequencing advice has aged better than most technology writing. Its first practice on vendor selection is unambiguous: define vendor selection and evaluation, or acceptance, criteria at the outset.
The examples it gives are cultural fit, skill set, industry knowledge, proposed transition plan, past performance and reputation. The point is the sequencing rather than the list. Criteria written after you have met three charming founders are criteria shaped by three charming founders.
So write down four things first.
Start with the business outcome rather than the feature list. "Cut the time our operations team spends reconciling orders from six hours a week to under one" is a brief. "Build an order dashboard" is a solution you picked before diagnosing anything, and it invites three firms to quote you the same wrong thing.
The difference between the two sentences is the difference between three proposals and one.
Next, name the constraint that actually binds: budget, deadline, or scope. One of them is real and the other two will flex. Firms price and staff completely differently depending on which one it is, and a firm that does not ask you in the first call is not planning the work.
Third, settle who owns the decision internally and who can say no. Evaluations with four stakeholders and no decider run for months and then select by exhaustion.
Last, establish whether you should be buying this at all. Some of what looks like a development project is a configuration problem, a process problem, or a hiring problem. Whether you need an outside team or an internal one is a genuinely different question from which outside team to pick, and it is worth resolving first, which is the ground our guide to building a technical team covers.
Five firms is too many and two is not a comparison. Three is right: enough to see genuine variation in how the same brief gets interpreted, few enough that you can run a real discovery call with each.
Where you find them matters less than how you filter them. Directory rankings are ordered by review volume and, on some platforms, by whether the firm pays for placement, so treat a directory as a source of candidates rather than a ranking. Referrals from someone who has shipped a comparable product are worth more than any listing, because that person can tell you what the firm was like in month seven.
Filter hard on two things before you spend a call. The first is whether the firm has built something with the same shape as your project, which is not the same as the same industry. A two-sided marketplace, a regulated data workflow, a hardware-connected app, and a content site are four different disciplines, and structural overlap predicts far more than sector overlap does.
Those four are the axis to filter on, and the industry is not.
The second is whether you can find evidence of delivery that the firm did not write about itself. Review platforms are imperfect, but a firm with twenty client interviews on record has been examined in a way that a firm with a testimonials page has not. Our own notes on vetting an outsourced team go further into what that evidence should contain.
One caution on sourcing, since it shapes the whole shortlist: an onshore team, a distributed one, and a staffing arrangement are three different purchases, and comparing them on headline rate alone will mislead you every time.
Everything worth knowing about a firm collapses into six dimensions. The value is not in the list, which is unsurprising. It is in assigning each one a weight before the calls start, so that a strong answer on a criterion you decided was minor cannot quietly dominate your impression.
| Criterion | What you are actually testing | Default weight |
|---|---|---|
| Structural fit | Have they built this shape of system, not this industry | 25% |
| Process and discovery | Whether scope gets pressure-tested before money is committed | 20% |
| The team you get | Named people, seniority, continuity, who is on your project in month seven | 20% |
| Commercial terms | Pricing model, change-order mechanics, what a cap actually caps | 15% |
| Security and IP | Ownership on payment, access from day one, supplier risk posture | 10% |
| Communication | Response times, escalation path, who tells you bad news | 10% |
The weights above suit a first custom build at a company without in-house engineering. Move them deliberately. If you already have a CTO who will own the system afterward, structural fit matters less and the team-continuity weight matters more, because your constraint is handover rather than judgment. If the product handles regulated data, security stops being a 10% row and becomes a gate: a firm that fails it is not scored lower, it is removed.
Written down before the calls, the weights are a decision rather than a recollection.
If nobody internally can evaluate the technical answers, that gap is worth closing before the evaluation rather than after, and a fractional CTO sitting in on three calls will pay for itself in one avoided mis-hire.
The twelve questions below make those six criteria visible. Ask every firm the same twelve, in the same order, and write the answers down during the call rather than after it. The pattern you are looking for is specificity: strong firms answer with a named project, a named person, or a number, and weak firms answer with a philosophy.
| # | Question | What a strong answer sounds like | What a weak answer is hiding |
|---|---|---|---|
| 1 | What have you built with the same structure as this? | A named system, what made it hard, what they would do differently | Industry name-dropping with no structural match |
| 2 | Which parts of my brief do you think are wrong? | A specific disagreement, argued | "It all sounds great" |
| 3 | What would you need to see before quoting a number? | A discovery phase, priced separately and briefly | A full quote, immediately |
| 4 | What does your discovery produce that I keep? | Acceptance criteria, flows, a scoped backlog, all yours | A proposal document |
| 5 | Walk me through a project that went badly. | An honest account with what changed afterward | "We haven't had one" |
| 6 | How do you decide something is finished? | Written acceptance criteria agreed before the build | "When you're happy with it" |
| 7 | Who exactly works on this, and what else are they on? | Names, seniority, allocation, holiday cover | "Our team" as a collective noun |
| 8 | What happens if that person leaves mid-project? | Documented handover, pairing, shared context | Reassurance without mechanics |
| 9 | What happens when I change my mind in month four? | A written change-order process with pricing rules | "We're flexible" |
| 10 | What is not included in this number? | Third-party licenses, hosting, post-launch support, data migration | A single figure with no exclusions |
| 11 | When does IP transfer, and when do I get repository access? | On payment, and from day one respectively | Handover at the end of the project |
| 12 | Which two clients can I call, including one where it got difficult? | Two names, one of them awkward | Curated references only |
Questions three and four are the ones firms find hardest, because a real answer means proposing a paid discovery phase before quoting the build, which costs them the appearance of a simple yes.
Question five and question twelve do most of the work, and both are about whether a firm can discuss its own failures without defensiveness. Nobody has a clean record over a decade of building software. A firm that claims one is either new, or managing you.
Scoring is where most evaluations quietly collapse back into a gut call, so keep the mechanics crude on purpose. Knowing how to choose a software development company comes down to this step, because three plausible finalists is the normal outcome and impressions cannot separate them. Give each criterion a mark out of five, multiply by its weight, and total it. A three is "answered specifically, nothing remarkable." A five requires evidence you could show someone else.
The discipline is scoring immediately after each call, before the next one. Scores recorded from memory a week later are not measurements, they are recollections, and recollections favor whoever was most likable.
Two rules keep the numbers honest. Any score of five needs a note saying what the evidence was, which will delete roughly half of them. And any criterion where all three firms score the same is a criterion that is not discriminating, so either your question was too easy or that dimension is not where your risk lives.
Expect the totals to land close together, often within a few points. That is a useful result rather than a failure of the method, because it tells you the decision rests on the weighted criteria you cared about most, and you can go and interrogate those two rows specifically instead of re-reading four proposals.
A signed contract is where an evaluation either pays off or turns out to have been theater, and the sequencing here is worth getting right. That 2001 GAO summary of commercial practice also puts contract negotiation before the final choice: among the practices it records is to make final vendor selections after contract negotiation rather than before it.
That inverts how most software purchases run. Pick the winner first and you negotiate with nothing left to hold back, because both sides know you have stopped talking to the others. Negotiate with your top two still live and the terms below stay genuinely negotiable.
Four mechanics then matter more than everything else in the document.
Four commercial models cover almost every engagement you will be offered, and each one moves risk to a different side of the table.
| Model | Fits when | The risk it carries |
|---|---|---|
| Fixed price | Scope is genuinely stable and fully specified | Contingency is priced in, and every change is a negotiation |
| Time and materials | Scope will evolve as you learn | No ceiling unless you add one |
| Capped time and materials | Most first builds | Requires a real discovery phase to set the cap honestly |
| Dedicated team | Ongoing product work past launch | You are buying capacity, so you must supply direction |
Capped time and materials is the model most first-time buyers should ask for and few are offered. You bill hourly against a hard ceiling the firm cannot exceed without a written, approved change order, usually with an obligation to flag when spend passes a set fraction of the cap.
That combination gives you the flexibility of hourly work and the budget certainty of a fixed bid, and it forces the difficult conversation early rather than at 90% spent. Where the money actually goes across these models is worth understanding before you negotiate one, which our breakdown of software development costs sets out in detail.
Acceptance is the term buyers skip and later wish they had not, because acceptance is the moment risk transfers to you. Before it, the firm carries the obligation to make the thing work. After it, the warranty period starts and the liability cap engages.
Acceptance should therefore be defined against written criteria agreed during discovery rather than against a feeling, and a portion of the fee, commonly ten to fifteen percent, should sit unpaid until the software passes those criteria.
Before that moment and after it, two different people are carrying the project.
Change orders need a threshold, otherwise every small request becomes an argument about whether it counts. The GAO report names a workable one from commercial practice: declare a significant event that can lead to a change in the contract, with a volume deviation of fifteen percent as its worked example. Borrow the idea. Anything under your threshold is absorbed, anything over it produces a written order with its own price and schedule impact before work starts.
The fourth mechanic is ownership. IP should assign to you on payment rather than at project end, and in some jurisdictions the developer retains ownership by default unless the contract says otherwise, so silence in the document is not neutral. Ask for repository access from day one too, since code you cannot see is code you cannot value.
This is the clause to put in front of a lawyer rather than a checklist. Assignment wording, the treatment of pre-existing and third-party components, and what happens to ownership if the engagement ends early are all jurisdiction-specific, and nothing in this article is legal advice.
Two further provisions are worth ten minutes each. The first is escrow. Where your business will depend on software a firm continues to host or maintain, a source code escrow arrangement holds the code with a neutral third party and releases it to you on defined triggers such as the firm's insolvency or its failure to support the system.
The second is security, which deserves a named standard rather than a vague assurance. NIST publishes a full framework for cybersecurity supply chain risk management, which exists precisely because organizations rarely have visibility into how the technology they acquire was built.
You do not need to implement it. You need to ask a supplier whether anything like it shapes how they handle your credentials, your data and their own dependencies, and to notice whether the answer has any structure at all.
Most warning signs are ambiguous in isolation and obvious in combination. These are the ones that have proven reliable.
The cheapest bid deserves particular scrutiny, because underpricing is usually a plan rather than an oversight. One founder's public write-up of a website engagement quoted at thirty to forty hours and roughly $5,000 to $7,000 records it reaching $46,000 across eight months, with the proposed remedy being a monthly retainer to unblock work that had stalled.
Three ordinary contract terms, two of them missing, and no point at which it ends.
That account, discussed at length on Reddit, is anecdotal as such write-ups are. The mechanism behind it is not exotic though: hourly billing, no ceiling, and no written definition of done.
Almost everything that determines the outcome of a software engagement is settled before anyone writes code: whether the brief described an outcome or a solution, whether the criteria were weighted before the calls, whether acceptance was defined in writing, and whether the contract said what happens when things change.
The firms worth working with will recognize this process and cooperate with it, because a buyer who has done this work is easier to build for. That reaction is itself a signal. A firm that finds your acceptance criteria and your change-order threshold tiresome is telling you how month six will go.
When we ran discovery for Honest Game, the work produced acceptance criteria for each user scenario and surfaced edge cases such as fifth-year students before anything was built. That is what let the project absorb the NCAA revising its requirements partway through, and you can read the full account of that build to judge whether that kind of scoping fits your project.
We publish no rate card, deliberately, because scope drives everything. The only public numbers on us sit on our Clutch profile, which reports an hourly band of $150 to $199 and records our smallest engagement at $10,000. Being able to find that much about a firm before a first call is a reasonable minimum to ask of anyone on your shortlist.
Buy the evaluation, not the code. You can assess process, references, contract terms and communication without reading a line of anything, and those four carry most of the risk. For the technical rows, borrow judgment: a fractional CTO or a trusted engineer sitting in on three discovery calls will hear things you cannot. Knowing how to choose a custom software development company is mostly about refusing to score dimensions you cannot actually assess.
Three firms, four to six weeks. Week one writes the brief and the weighted criteria, weeks two and three run the discovery calls, week four collects proposals and reference calls, and the remainder negotiates. Evaluations that run longer usually do so because nobody defined who decides.
The framework is identical and two weights move. How to choose a web development company leans harder on performance, accessibility and content workflow, while how to choose a mobile app development company adds store review, device fragmentation and release cadence, which means an update cannot simply be pushed on a Friday. Ask the same twelve questions, and move weight onto structural fit and commercial terms.
A project engagement suits defined scope with a finish line. Deciding how to choose a dedicated development team is the right question once product work is continuous and you need capacity rather than a deliverable, but it transfers direction-setting to you, so it only works if someone internally owns the roadmap.
Stop spending, get a read on the codebase from someone with no stake in the previous engagement, and separate what is recoverable from what is not. Partial rebuilds are common and often cheaper than they sound, since the domain knowledge and the data model usually survive even when the code does not.
Send us the brief and the three firms you are weighing, and we will tell you which questions we would push hardest on. We do that even when the honest answer is that somebody else on your list fits the work better than we do. Contact us and tell us where things stand.
