How to Choose a Software Development Company

In the way one might select a caterer, most buyers go about choosing a software development firm: they look at the portfolio, put price on the table, have a pleasant call and then put pen to paper. Come six or twelve months down the line, however, a rescue developer will be left sifting through the codebase with no decision log, no dev environment that runs and no one to take ownership of the pieces that are failing. One could call it bad luck but it is really just what you get when you make your choice on the wrong signals.

For such an imprecise subject, the data is plain to see. Junade Ali and J.L. Partners looked at 600 engineers in 2024 and determined that having requirements clearly on paper made for 97% better odds of success. A 2026 database of 1,091 startup failures attributes 42% of them to a lack of market need, while a review of twelve SaaS shutdowns from 2024-25 shows they all did without proper validation. None of these were the fault of substandard coders; they were scoping, contracting and governance issues.

This guide is meant to steer you toward the kind of signals that are predictive of the end result: discovery discipline, contract structure, team continuity and post-launch traceability. We have put portfolio flash and hourly rates lower on the list for a reason.

Selection Is Risk Management, Not Shopping

When you buy custom software you are not procuring a finished product. You are entering a partnership where the other side will make hundreds of decisions for you, many of them unseen until they come with a price tag. Look at the public failures, from the NHS National Programme for IT to Lidl’s $580M SAP program or the FBI’s Virtual Case File. They all have the same profile: misaligned incentives, poor governance and an absence of honest talk over what was being built.

The mechanics are identical for your project, even if the scale is different. We have seen founders put $40k to $75k down the drain by taking the first fixed quote and only finding out after twenty weeks that the login flow is broken. The right way to think of it is that you are not purchasing code so much as a set of behaviors. How does the team deal with ambiguity? What do they leave behind for the next person? Your scorecard should be testing for that.

Define Your Constraints Before You Talk to Vendors

There is nothing like a founder who walks into a vendor call with a half-baked notion and expects the vendor to put it in order. They will put it in order, certainly, but in whatever direction yields the biggest contract since they have no other guide.

Do some work before the first call. Put three sets of constraints in writing:

• Business. Your budget ceiling, time to market, internal skills and regulatory posture. If you are under HIPAA or GDPR, put it on the first page.
• Technical. Performance floors, security baselines and the systems you have to integrate with. If your user base is still on Internet Explorer, the whole stack conversation changes.
• Organizational. Who has the authority to make product calls and in what time zone. This is the detail everyone omits and the one that wrecks delivery.

Put together a one-pager on the problem and the audience, what the product has to do on day one and why it is worth building. If a vendor cannot put some pointed questions to you on that page, do not expect them to start once your deposit is in the bank. For more on structuring the early phase, the product discovery process is worth a read.

Be honest about whether your problem is fuzzy or fixed

An execution team can price and ship if the edge cases and integrations are already charted. But if you know the outcome and not the solution, you want a partner who is at ease with prototyping and revision. To confuse the two is the costliest error here; a team that will only build what is written down is of no use in determining what ought to exist.

The Scorecard That Beats Gut Feel

Do not rank vendors on the strength of the pitch. Use a weighted rubric. The more rigorous 2026 procurement frameworks tend to assign their criteria in this manner:

It is the ordering that counts more than the precise figures. You will not find cost or how well the sales staff can talk up agile at the top. You will find architectural evidence and security. Build a regulated system and security goes up; a consumer MVP and process maturity takes precedence. Make those adjustments with purpose. Have two people from your side score independently and compare. The best discussion comes from any disagreement there may be.

Questions That Force Real Answers

Vendor interviews have a tendency to be overly civil. Stack, timeline, price. It reveals very little of how the company operates when things get complicated. Ask something like:

• Can I interview the lead engineer this week? There is plenty of complaint on X and Reddit about the bait-and-switch of a senior engineer making the pitch while a junior is left to ship the work. Contractual language on continuity is one thing, but meeting the person in charge is another. – Put an ADR from a recent project in front of me. Mature teams use Architecture Decision Records to make the case for Postgres instead of Mongo, or a monolith over microservices. You will know where you stand if there is not a single person on the line who can tell you what one is.
• Give me your DORA metrics for the past three projects. I want to see the numbers on deployment frequency, lead time, change fail rate and mean time to recover. Any team can put on the vocabulary of ceremonial-agile; real ones have the data to back it up.
• Describe a project that did not go well and your follow-up. There is always one with any serious outfit. Those who say otherwise are either new to the game or being less than honest.
• Show me a runbook and handover doc from another client and tell me what happens after launch. We see it as rescue developers: the first version is fine, but six to twelve months in the changes become risky and slow because the next person was left in the dark.
• Who has repo access and when? Who owns the code the instant it is written? The answer should be day one and you.
• Walk me through the last scope change you had to manage. If they cannot lay out the mechanics, they do not have a process for it.

There is also value in noting how much the vendor resists. Good engineers will challenge an assumption or put forward an alternative; they will tell you an idea will not work as put forward. If everyone is nodding along, you are putting order-takers on the payroll and they will not protect you from your own scope.

The Contract Is an Engineering Constraint

You would be surprised how much contract structure dictates technical results, something the academic research from Lacity and Willcocks or Gefen et al. makes clear. Fixed-price arrangements breed adversarial change orders and under-scoping. Leave it to pure time-and-materials and you get scope creep with no governance. Look at the NHS NPfIT postmortems and you can see the bloated, unused systems that come from paying for output volume rather than user outcomes.

What stands up to reality is a milestone-based approach with proper risk management and change control. A fair contract will stipulate:

• An upfront payment of no more than 25%, with the rest contingent on testable deliverables.
• Written work-for-hire and IP assignment. The design files, domain models, data and code are yours.
• Source-code escrow or immediate repo access so a vendor’s problems do not become existential for you.
• An exit clause granting you rights to everything that is running, documented and complete.
• A RACI matrix to pin down accountability when things break.
• A change-control process with the rules on pricing and timeline set in stone before you start.

For a deeper look at the tradeoffs between fixed price and time and materials, this piece is worth reading. And for the actual document, the software development agreement guide from LegitTAI will cover the clauses a first-time buyer tends to overlook.

Pilot Before You Commit

A $250k build should not be signed on the strength of three sales calls. The 2026 buyer guides are all pointing to a paid pilot of four to six weeks, say $3k to $8k, to vet the engagement first. Some even put two vendors to the test on the same small scope. It may seem like overkill until you put it against the expense of a botched six-month project.

This is not free strategy work. The pilot is to see how they handle ambiguity in scoping, the quality of their documentation, and if the lead engineer you met is the one at the keyboard. See what they leave behind – a readable README, a decision log, tests that spell out expected behaviour – if you part ways.

Practitioners such as Prayag Dalal and Shriharsha have been saying for two years on X to score on traceability, not velocity or price. If a new hire cannot get up to speed with the codebase in a week, it is a liability no matter how quickly it shipped.

Reference Calls That Actually Tell You Something

Do not be taken in by reference calls; they are often just theater with a vendor parading three satisfied clients for half an hour. Ask about the hard parts:

• How did they deal with a major shift in requirements?
• What does the system look like eighteen months in and who is maintaining it?
• Did you ever feel locked in and what would it cost to walk away?
• Where did they push back and were they right to?
• Would you work with them any differently?

Logo walls and anonymized quotes are the flimsiest kind of proof. You want a named reference on the phone willing to be candid.

How Much Should This Cost

The sticker price is only part of the story given the variance in scope. Here are some 2026 figures that are consistent across the board:

• Nearshore or offshore MVPs: under $40k
• Custom business apps: $50k-$250k
• Enterprise or AI platforms: $500k+
• Global median for a developer: in the $37/hour neighbourhood
• Senior CEE talent: $50-$120/hour
• US architects and leadership: $120 to $250+/hour

Think of these as ranges, not hard and fast quotes. A good rule of thumb in budgeting is to put the one-time build cost (design, engineering, infrastructure, testing, rollout and training) in a different column from what you will be paying for on an ongoing basis, such as support SLAs, licenses and maintenance. In truth, it is the second figure that is more likely to put a product out of business; too many founders are happy to fund the build but have not put aside the money for the two years following launch. For a fuller accounting of where the numbers come from, we have a piece on software development cost estimation.

Where Refact Sits in This Picture

Over 12 years we have put more than 200 projects in front of our clients as a US-based studio. We keep discovery, strategy, design and engineering under one roof so the person who ships the code is never two contracts removed from the one defining the problem.

Take the case of a project management consultant who came to us with a vague notion for an AI assistant to do “everything” for his clients. The real work was done before we wrote a line of code. Using our Workform blueprint process, we reined in the scope and turned the idea from a task generator into something more useful: an assistant that pulls data from Slack, email, Asana and meetings. We were able to ship a focused MVP rather than the sprawling thing in the original brief.

Or consider when the Keck School of Medicine at USC had to take nearly ten years of newsroom content and faculty pages off a tangle of subdomains. The migration script was not the difficult part; it was safeguarding the editorial workflows and citations. Because we took the time in discovery to identify those constraints, the Keck platform migration went ahead without losing a reader.

For more on the kind of engagement we have in mind, look at our product design and hiring a product development team pages. If the question of outsourcing is on your mind, there is a longer discussion on how to outsource software development.

Red Flags Worth Walking Away From

There are certain telltale signs of a bad engagement that are consistent enough to use as a filter:

• A fixed-price quote given after half an hour on the phone. They are pricing on hope and you will make up the difference in change orders down the road.
• Nothing but salespeople on the line. When engineers are nowhere to be found in the selection phase, they will be absent at delivery.
• An unwillingness to put a name to the lead engineer or provide references. That is a bait-and-switch.
• Silence on testing or post-launch support until you bring it up. Either they have not considered it or they would prefer you did not.
• Portfolio links that go nowhere. Make the thirty minutes to check them.
• Vague answers to pointed questions. “We are agile and will adapt” is not much of an answer if there is no process to back it up.
• Big upfront payments for ill-defined milestones. You will find this in most horror stories.

None of these is an absolute and any one can be put to rest with an explanation. But a couple in the same conversation is a pattern.

The First 90 Days After You Sign

It does not matter how well you choose unless the first sprint goes smoothly. Before the kickoff meeting make sure you have contract clarity, a written plan for support and maintenance, and unmediated access to the working team, not just the account manager. By week one you should have repo access, a functioning CI/CD pipeline and some reading material on why the initial architecture was chosen.

Launch is the beginning, not the end. When everyone makes the launch date their finish line you get the rescue-developer scenario and a “cursed codebase” six months later. A proper partnership has the second year planned before the first month is out.

At Refact, our discovery process is designed to iron out what needs to be settled before development gets underway. There is nothing particularly interesting in getting it right. It is about making sure everything that follows can happen.