How to Choose a Custom Software Development Company: A 10-Question Framework

Choosing a custom software development company is a procurement decision disguised as a technical one. Most firms can write code to a specification; far fewer can absorb a changing requirement, integrate with systems nobody fully owns, and hand back something your team can maintain. The ten questions below are designed to tell those two groups apart before you sign.

Key Takeaways

• Evaluate delivery evidence, not capability claims. Every shortlisted firm will say it does agile, DevOps, automated testing and AI-assisted development. Ask what their last comparable engagement actually shipped, how often, and what broke.
• The named team is the deliverable. The single most reliable predictor of a bad outcome is a proposal team that is not the delivery team. Get names, and get them in the contract.
• Price the same small first phase with everyone. The spread in how firms scope an identical piece of work reveals more than the spread in their rates.
• Ask what happens when the requirement is wrong. Every custom build has a requirement that turns out to be wrong in month four. How a firm answers that question is how your project will actually go.
• Exit terms are a quality signal. A firm confident in its work will happily agree that the code, the pipeline, the infrastructure-as-code and the credentials are yours on day one.

In This Guide You Will Learn

• What you are actually assessing
• Why vendor selection fails more often than engineering does
• The ten questions, and what good answers sound like
• How the questions map to risk
• Comparing engagement models
• A worked shortlist: three firms, one brief
• Where this evaluation goes wrong
• The evaluation sequence
• Best practices
• Evaluation checklist
• Frequently asked questions

The Problem With How Most Shortlists Are Built

A typical shortlist is assembled from a search, three referrals and whoever answered the RFP most enthusiastically. Each firm then presents a deck with the same eight logos, the same agile diagram, and a case study in which delivery was 40% faster. By the third meeting every vendor looks identical, and the decision defaults to price.

That process selects for sales capability, not delivery capability, and the two are only loosely correlated — not because firms are dishonest, but because pre-sales and delivery are staffed by different people with different incentives, and nothing in a standard evaluation forces the second group into the room.

The correction is not a longer RFP. It is a small number of questions a sales team cannot answer without pulling in someone who has actually delivered.

How to Choose a Custom Software Development Company: What You Are Actually Assessing

Knowing how to choose a custom software development company means establishing, before you are contractually committed, whether the firm can deliver a working system into your specific organisational context — not whether it can write software in the abstract.

That distinction matters because almost every firm on your shortlist can write software in the abstract. The variables that determine outcomes are elsewhere:

• Who actually does the work, and what else they are staffed on
• How the firm behaves when the requirement changes, which it will
• What "done" means, in writing, before the first sprint
• How the work will be tested, and against what environments
• What you own when the engagement ends, amicably or otherwise

None of those are technical questions. All of them are answerable in a single well-run conversation, and all of them are routinely skipped.

If you are still deciding whether to build at all, start with the economics of custom software development — buy the commodity, build only the thing that differentiates you — and come back to vendor selection once that decision is settled.

Why Does Vendor Selection Fail More Often Than the Engineering?

Because the engineering problems are visible and the selection problems are not.

When a build goes badly, the post-mortem usually lands on a technical cause: the architecture did not scale, the integration was harder than expected, the test coverage was thin. Trace those back and they generally resolve to a decision made before any code existed — a scope fixed on unknowable requirements, a team substituted after signature, a definition of done that was never written, a test strategy that assumed environments that did not exist.

Two forces have made this worse recently.

The first is AI-assisted development. In Stack Overflow's 2025 Developer Survey of roughly 49,000 developers, 84% of respondents said they use or plan to use AI tools in their development process, up from 76% the year before. In the same survey, trust is strikingly low: 3.1% highly trust the accuracy of AI output and 29.6% somewhat trust it, against 26.1% who somewhat distrust it and 19.6% who highly distrust it (Stack Overflow, 2025). Read those two numbers together and the implication is clear — AI-assisted code is now near-universal in delivery, and the developers producing it mostly do not trust it. Whether your vendor has a review practice that accounts for that is now a first-order question, not a curiosity. We have written separately about what a verification pipeline for AI-generated code should look like.

The second is that capability has commoditised faster than judgement. The gap between an average firm and a strong one used to show up in whether they could build the thing. Increasingly it shows up in whether they tell you early that you asked for the wrong thing.

The Ten Questions

Each question below comes with what a strong answer sounds like and what should end the conversation. Ask them of the delivery lead, not the account manager.

1. Who specifically will work on this, and what else are they staffed on?

Strong answer: Named individuals, their allocation percentage, their other current commitments, and a willingness to name them in the statement of work. A strong firm will also tell you who is not dedicated — the architect who reviews weekly, the DevOps engineer shared across three accounts — because that is normal and hiding it is not.

End the conversation: "We'll assign the right people once we start." The proposal team disappearing after signature is the most common and most damaging pattern in this market. If names cannot go in the contract, assume they will not be on the project.

2. What did your last comparable engagement actually deliver?

Strong answer: Deployment frequency, lead time from commit to production, change failure rate, and time to restore — the four DORA measures — for a real engagement, with the caveats. Or, if they do not measure those, an honest "we don't track that, here is what we do track."

End the conversation: A percentage improvement with no baseline. "We reduced testing time by 60%" is unfalsifiable without knowing what it was before, how it was measured, and over what period.

3. What is your definition of done?

Strong answer: A written artefact that predates your project. It should mention code review, automated test coverage expectations, security scanning, documentation, and deployment to a production-like environment. Ask to see the actual document.

End the conversation: Done means the developer says it is done. This single gap generates more end-of-project disputes than any other.

4. How do you handle a requirement we got wrong in month four?

Strong answer: A specific mechanism — a change budget carved out of the estimate, a rolling re-prioritisation at a fixed cadence, an explicit assumption register reviewed monthly. The best answers include an example of a time they told a client the requirement was wrong.

End the conversation: "We'd raise a change request." That is a commercial process, not an engineering answer, and it tells you the contract will be defended rather than the outcome.

5. What is the test strategy, and what environments does it assume?

Strong answer: Test pyramid shape, what is automated at each level, how test data is produced and refreshed, and — critically — which environments exist and who provisions them. Test data management is where enterprise builds quietly stall, and a firm that raises it unprompted has been burned by it before.

End the conversation: Testing described as a phase that happens near the end. It means the schedule has a cliff in it that nobody has priced.

6. How much of this will be AI-generated, and who reviews it?

Strong answer: A candid figure, where they allow it and where they do not, and review proportionate to risk — stricter for authentication, payments, data handling and anything touching a compliance boundary.

End the conversation: Either "we don't use AI" (improbable at 84% adoption, and worrying if true) or "our developers use it however they like." Both are unmanaged risk, pointing in opposite directions.

7. Where does the source code live, and what happens if we stop?

Strong answer: Your organisation's repositories, your cloud accounts, your CI/CD, from day one. Infrastructure as code committed alongside the application. A written exit clause covering credentials, documentation, and a handover period.

End the conversation: Code in the vendor's repositories, transferred "at project completion." That is leverage, and it will be used at the least convenient moment.

8. Can we speak to a reference we choose rather than one you offer?

Strong answer: Yes, with a reasonable confidentiality constraint. A strong firm offers a list broader than its three favourites and lets you pick.

End the conversation: A single managed reference call with the account manager listening. Ask for a client whose project went badly; the willingness to connect you is more informative than any success story.

9. How do you handle the integration estate?

Strong answer: Questions back at you. Which systems, which protocols, who owns the interface contracts, what the rate limits are, whether a test instance exists. Integration surface — not feature count — best predicts enterprise delivery time, and a firm that estimates without interrogating it is estimating fiction.

End the conversation: An estimate that does not change when you mention a third integration.

10. What does your last failed project look like?

Strong answer: A real one, described specifically, with their share of the responsibility owned rather than distributed. Everyone has one. The answer tells you whether the firm learns or narrates.

End the conversation: "We haven't had one." This is never true, and a firm willing to say it under mild pressure will be willing to say other things under commercial pressure.

How the Questions Map to Risk

Each question exists because it predicts a specific failure. The diagram below maps them onto the four stages where custom software engagements actually break down.

The pattern worth noticing: the cost of fixing each failure rises sharply from left to right, while the cost of asking about it is identical at every stage. Staffing problems are cheap to avoid and expensive to endure. Exit problems have no remedy at all once you are in them.

Comparing Engagement Models

The commercial shape of the engagement constrains behaviour more than any clause in the contract. Choose it deliberately.

Two practical notes. Rate is not cost — a firm at half the hourly rate and one third the velocity is more expensive, and that is invisible on a rate card. And price the same phase one with everyone: an identical, small, well-defined first piece of work priced by all three shortlisted firms is more informative than any amount of proposal reading. The same principle applies when selecting a QA consulting partner.

A Worked Shortlist: Three Firms, One Brief

The following is a worked illustration built to show how the framework behaves, not a client engagement. The figures are modelled to make the arithmetic legible; they are not measured outcomes.

The brief: replace an internal order-management tool. Four integrations (ERP, identity provider, a carrier API, a data warehouse). Twelve-month horizon. One internal product owner at 50%.

Firm A is cheapest on every visible axis and fails four of the five questions that predict the expensive failures. Firm C costs most per hour and is the only one that interrogated the integration estate — the variable most likely to decide whether this project takes twelve months or twenty.

The decision this framework produces is usually not "pick the cheapest" or "pick the most expensive." It is "run a paid phase one with B and C, and drop A."

Where This Evaluation Goes Wrong

Four failure modes recur, in our own engagements and in those we inherit.

Asking the questions of the wrong person. An account manager will answer all ten plausibly. The answers are worthless unless they come from whoever will run delivery. If the firm will not put that person in the room before contract, that is itself the answer.

Treating the checklist as a scoring exercise. Two of these — the named team and code ownership — are closer to gates than scores. A firm that fails either is not improved by scoring well on the other eight.

Confusing certification with capability. ISO 27001, CMMI and partner badges tell you a process was documented and audited, not whether the four people assigned to you follow it. Ask which certified process applies to your engagement specifically.

Under-scoping your own side. A 50%-allocated product owner who is genuinely available beats a 100%-allocated one who is in other meetings. If your organisation cannot supply decisions at the rate the engagement consumes them, no vendor choice will save the project — the same dynamic that sinks QA outsourcing arrangements.

The Evaluation Sequence

Run the evaluation in this order. Each stage is designed to eliminate candidates cheaply before the next stage costs you anything.

Best Practices

• Put the named team in the statement of work, with a notice requirement for substitution. This one clause removes the most common failure mode in the market.
• Run stage five with two firms. A parallel paid phase one on a real, small piece of work costs a fraction of a twelve-month build and is the only evaluation that tests delivery.
• Own the repositories, the cloud accounts and the CI/CD from commit one. Not at project completion, not at a milestone. Day one.
• Write the definition of done before the first sprint, jointly, and treat disagreements about it as useful information rather than friction.
• Assign a real internal owner. Someone with authority to decide, not to escalate. The vendor is rarely the binding constraint on decision latency.
• Agree the test and environment strategy in the architecture phase. If your build is significant enough to need independent assurance, engage that capability at the same time — the pattern for hiring QA consultants alongside a build partner is well established and keeps the two accountabilities separate.
• Re-run questions 1 and 5 at month three. Teams drift and test strategies erode. Both are recoverable early and expensive later.

Evaluation Checklist

Use this before signature. Anything unticked is a risk you are accepting knowingly rather than one you are discovering later.

• Delivery lead — not just the account manager — has been in the room
• Named individuals and allocations are in the statement of work
• Substitution requires written notice and your agreement
• A written definition of done exists and is project-specific
• Test strategy names the environments and who provisions them
• Test data approach is documented, including production-data handling
• AI-assisted development policy stated, with review proportionate to risk
• Source control, cloud accounts and CI/CD are in your organisation from day one
• Infrastructure as code is a contractual deliverable
• Exit clause covers credentials, documentation and handover period
• At least one reference you selected, ideally including a difficult engagement
• All four integration points interrogated, with rate limits and test instances confirmed
• Identical phase one priced by every shortlisted firm
• Your own product owner named, with decision authority and real availability
• Engagement model chosen deliberately, not inherited from the vendor's template

Frequently Asked Questions

How do you choose a custom software development company?

Evaluate on delivery evidence rather than capability claims. Ask for the DORA-style delivery metrics of a comparable engagement, the names of the people who will actually do the work, a written definition of done, the test and environment strategy, the source-control and IP arrangement, and a reference you select rather than one they offer. Firms that can answer those six without preparation are materially different from firms that answer them with a capability deck.

What questions should I ask a software development vendor before signing?

The highest-signal questions are the ones a sales team cannot answer alone: who specifically is on the team and what else are they staffed on; how do you handle a requirement we got wrong in month four; what is your definition of done; what happens to the code, the pipeline and the credentials if we end the contract; how much of this will be AI-generated and who reviews it; and what does your last failed project look like.

How much should a custom software development company cost?

Rates vary by geography and seniority, and a low rate is not a low cost if velocity is half. Compare on cost per delivered increment over a quarter rather than on hourly rate. Ask every shortlisted firm to price the same small, well-defined first phase; the spread in how they scope it tells you more about how they think than the spread in price does.

Should I choose a fixed-price or time-and-materials contract for custom software?

Fixed price suits work whose scope is genuinely knowable in advance, which in practice means integrations, migrations and replacements of an existing system. Time and materials suits discovery-heavy product work. The common failure is fixed price on unknowable scope, which converts every change into a commercial dispute and pushes the vendor to defend the specification rather than the outcome.

What are the warning signs of a bad custom software development partner?

A named team that changes after signature; no written definition of done; testing described as a phase rather than a practice; refusal to give a reference you chose; source control held in the vendor's own account; and an estimate that does not go up when you add a third integration. Each of these predicts a specific failure mode, and each is visible before you sign.

Conclusion

The ten questions are not a scoring rubric. They are a way of forcing a conversation most vendor evaluations never have — one in which the people who will actually deliver the work explain how they will do it, before you are committed.

Firms that are good at delivery generally enjoy that conversation. They have the DORA numbers, the definition of done, the test strategy and the failure story, and they are pleased someone finally asked. Firms that are good at selling redirect toward the deck. That divergence is the signal, and it costs one meeting to observe.

If you are working through a build decision now, read this alongside the economics of custom software development and a candid view of when an outsourcing partner is the right structure at all. Our software development services follow the same principle this guide argues for — build, integrate and assure as parallel tracks, the delivery team named, the code yours from the first commit. To test that against the ten questions, start a conversation.