How to Choose a Software Development Company

A friend once forwarded me an agency proposal that looked perfect. Beautiful deck. Logos of companies you’ve heard of. A timeline that fit the board meeting. Price that felt “aggressive but doable.”

Six months later the product wasn’t late so much as different — juniors on the repo, seniors only on status calls, and a change-order machine humming every time priorities moved. The deck hadn’t lied exactly. It had just described a company that exists mainly during sales.

That’s the failure mode this guide is about. Choosing a software partner is less about presentations and more about risk. CTOs who’ve written about it lately — Rahul Chauhan on Medium, Aksa Karsa’s red/green flag guide, Team Seven’s vetting checklist, Techradiant’s 2026 notes — keep pointing at the same early signals. Almost none of them are “do they have a nice website.”

Decide what you’re buying before you shortlist

Three different purchases get sold with the same slide:

1. Scoped build — named outcome, demo cadence, an end date that means something
2. Dedicated squad — capacity and judgment on your calendar, ongoing
3. Staffing — hands under your tech lead

If you need product judgment and shipping ownership, buy 1, then maybe 2. If you already have senior ownership and need bandwidth, say so out loud. Vendors who sell all three identically will optimize for the contract, not for the gap you’re trying to fill. I’ve watched founders buy “a team” when they needed “a product,” then wonder why nobody made product decisions.

Red flags that show up before the SOW

Generic answers to specific problems. Ask about your domain — logistics, clinical ops, fintech reconciliation — and listen for architecture, failure modes, data realities. If every answer could apply to any RFP on earth, you’re hearing sales depth, not technical depth. Chauhan’s Medium piece nails this: serious partners get specific fast.

They agree with everything. Competent partners push back on timelines, flag fuzzy scope, and name at least one term they want to negotiate. Blanket yes usually means problems get discovered after you’ve lost leverage. Esteban Herrera’s line (via CIO-facing practitioner roundups) still holds: the provider that says yes to everything often doesn’t know or doesn’t care.

Unrealistic dates. A complex platform “in a few weeks” is a template or a hostage situation. Timelines quoted before integrations and data are assessed are fiction with a Gantt chart.

Bait-and-switch staffing. Seniors on the call, “resource allocation based on availability” after signature. Ask for names of who writes the first PRs. If they won’t introduce builders before you sign, assume you’ll meet different people later. Put key-person language in the contract if continuity matters.

Price that buys the deal. A bid more than ~10% under everyone else often recovers through change orders or quiet quality cuts. Deep discounts aren’t generosity. They’re a financing strategy — and you’re the bank.

Vague proposals. Phrases like “full-featured platform” and “all necessary integrations” mean almost nothing. You want assumptions in writing, tech named, and a clear split between base scope and extras. If the proposal could be reused for a different client with a find-and-replace on the company name, keep looking.

No post-launch story. Who fixes production in month two? Who answers the security questionnaire? If the answer is a shrug, you’re buying a deploy ceremony, not a product.

References you can’t talk to. “All confidential” with zero callable references is a walk-away for a lot of CTOs. Real partners can usually produce someone who will speak candidly — even if names are under NDA and you get a warm intro instead of a case-study URL.

Green flags worth overweighting

These sound soft until you’ve been burned:

• Named engineers before you sign; you can meet the person owning the riskiest integration
• A staging URL and working software early — not status PDFs with traffic-light colors
• They refuse part of your wishlist for v1 and can explain why without sounding dismissive
• Itemized pricing with assumptions you can argue with
• Case studies with scope, timeline, and outcomes — not just screenshots of Dribbble-adjacent UI
• They work in your Slack and repo, not a parallel universe you have to chase
• They talk about activation and the month after launch, not only go-live champagne

On-site vs remote isn’t a morality play. Overlap hours where the hard path needs a human. A culture that depends on 10pm Slack heroics is a smell, not a flex.

Questions that cut through the deck

I keep a short list on my phone for intro calls:

1. Who opens the first pull request — by name?
2. Can I meet the engineer who owns the scariest integration this week?
3. What does a Friday look like — a URL or a PDF?
4. How do we change priority on Monday without a change-order tax?
5. Whose GitHub and staging is this going to live in?
6. What would you cut from our list for an MVP, and why?

Ask to see code — open source, a sanitized walkthrough, or a paid one-to-two-week pilot. People who ship usually tolerate technical diligence. People who staff often get oddly protective of process and allergic to repos.

A paid pilot costs money. A bad twelve-month engagement costs more.

A score you can run in a week

Rate each shortlisted vendor 0–2 on four axes:

• Named builders
• Visible working software
• Movable scope
• Post-launch ownership

A 6–8 is a partner candidate. A 2–3 is procurement theater. Don’t average an 8 on slides with a 1 on “who commits code.” I’ve watched boards do exactly that and then act surprised in month four.

For MVP shape and cost context while you evaluate partners: SaaS MVP guide · build costs.

If you’re talking to us

We’re a small senior team on purpose — named engineers, no bait-and-switch bench, a handful of people on one product at a time. We’ll tell you if a rules engine beats an LLM for your problem, and if your “MVP” is actually a platform in a trench coat.

If the better move is an in-house hire or a specialist shop, we’ll say that too. Choosing well is cheaper than a cheap vendor. The expensive part isn’t the day rate. It’s the year you don’t get back.