How to Choose a Bespoke Software Company

By Lazar Milicevic · Published July 15, 2026 · 10 min read

You have a workflow that's costing your team 15 hours a week, no off-the-shelf tool fits, and you've just started collecting proposals from custom software shops. The quotes range from $18k to $240k for what sounds like the same project, half the vendors want a discovery workshop before quoting, and the cheapest one keeps saying "we'll figure it out in sprint one." Picking the wrong partner here doesn't just cost money — it burns 6-12 months and leaves you with a codebase nobody wants to touch.

This is a decision framework for choosing a bespoke software company in 2026, written from the perspective of someone who has both built custom systems for clients and cleaned up after other agencies. I'll cover what actually matters, what to ignore, how to read a proposal, red flags, and a set of questions that force honest answers.

What "bespoke software" actually means in 2026

Bespoke software is a system built specifically for your business rules, integrations, and data — as opposed to configuring a SaaS product to fit. In 2026 the definition has shifted: most competent shops now assemble bespoke systems from a mix of custom code, hosted APIs (auth, payments, search, LLMs), and low-code glue, rather than writing everything from scratch. If a vendor is quoting six figures to build user authentication in 2026, that is a signal, not a feature.

The practical taxonomy looks like this:

Ranges are directional. What matters is that a vendor's proposal lands inside a sane band for the type of work — outliers in either direction need explaining. A $200k quote for an internal tool is not automatically a scam, but the vendor should be able to defend every line.

Criteria that actually predict success

Most RFP scorecards are theater. They rank vendors on "years in business," "team size," and "industry experience," which correlate weakly with whether the project ships. Here is what actually predicts a good outcome, ranked:

1. The person doing the technical scoping is the person who will lead the build. Not a sales engineer, not a "solutions architect" who disappears after signing. Ask directly: "Will the person on this call write code or review PRs on my project?"
2. They push back on your spec. A vendor who agrees with every feature you list is either desperate or lazy. Good engineers cut scope in the first call.
3. They have written post-mortems, changelogs, or engineering blog posts — public evidence they think in terms of shipped systems and known failure modes, not case studies.
4. They ship a small paid discovery or spike before quoting the full build. A fixed-price quote for a system they've spent one hour thinking about is a fantasy.
5. They own their staging + observability story. Ask how they'll know something is broken in production. If the answer is "we'll monitor Sentry," dig deeper. If there is no answer, walk.
6. They can name what they will not build. "We don't do mobile," "we don't do on-prem," "we don't take clients under $30k." Specialists ship; generalists estimate.

Notice what is not on that list: team size, office location, awards, Clutch reviews, or the number of "AI experts" on staff. In 2026 every agency claims AI expertise. What matters is whether they can point to a production system they run that uses LLMs responsibly — with evals, cost caps, and a fallback when the model is wrong.

How to read a proposal

A serious proposal has four sections you should be able to find in under two minutes: scope, assumptions, exclusions, and change process. If any of those are missing, the vendor is optimizing for signing, not shipping.

Here is what a healthy scope block looks like when translated into concrete terms:

scope:
  - Ingest CSV exports from HubSpot (daily, up to 50k rows)
  - Normalize + dedupe against Postgres customer table
  - Enrich via Clearbit API (rate-limited, cached 30 days)
  - Push cleaned records back to HubSpot via API
  - Slack alert on failed rows > 1% of batch

assumptions:
  - Client provides HubSpot private app token with rw:contacts
  - Clearbit account + budget owned by client
  - Postgres instance provisioned by client (we recommend Supabase or RDS)

exclusions:
  - No UI for browsing enriched records (Retool or Metabase suggested)
  - No historical backfill of pre-existing 400k contacts (separate SOW)

change_process:
  - Anything outside scope enters a change order log
  - Change orders quoted in hours + fixed price before work starts
  - No verbal approvals — must be confirmed in project channel

If your vendor cannot produce something this specific after a discovery call, they will discover the specifics on your dime during the build. Every "we'll figure it out later" line item is a future invoice with no cap.

Pricing models to understand:

• Fixed price: Vendor takes the risk. You pay more, but you know the number. Only works when scope is genuinely fixed — which is rare for real systems.
• Time & materials with a cap: Most honest model for custom work. Weekly hours + a not-to-exceed number. Vendor bills what they work; you get a ceiling.
• Sprint-based / retainer: Fixed monthly amount for a fixed team. Good for ongoing evolution, bad for greenfield builds with an unclear end.
• Milestone-based: Payment tied to shippable deliverables, not hours. Aligns incentives, requires clear acceptance criteria per milestone.

Avoid pure fixed-price for anything you have not scoped down to acceptance-test level. Avoid pure time-and-materials with no cap. The middle is where trust gets built.

Red flags, ranked by how much they will cost you

Some warning signs are cosmetic. Others predict a six-figure disaster. In descending order of pain:

Catastrophic:

• No access to the code repo during the build. If you cannot clone the repo on day one, you do not own the software.
• No CI, no tests, no environments beyond "prod." You are buying a prototype at production prices.
• Refuses to name specific people on the project. You will get whoever is on the bench.
• Charges extra for "handover" or "documentation." Both should be built-in, continuous, and free.

Serious:

• Every question routes through a project manager who cannot answer technical questions. Latency will compound.
• Their portfolio is all logos, no live URLs, no case studies with numbers.
• Contract has no exit clause. Assume you will want to leave; make sure you can.
• Proposal has zero mention of monitoring, logging, backups, or incident response.

Yellow flags (ask, don't reject):

• They subcontract. Fine if disclosed and the lead is in-house. Not fine if you find out later.
• They only work in one framework. Fine if it fits your problem. Not fine if they're forcing it.
• They want equity instead of cash. Sometimes legitimate, usually a sign they can't close paying clients.

Questions that force honest answers

Bring these to the second call, after NDAs but before contracts. The quality of the answers matters more than the answers themselves.

1. "Show me a repo from a recent client project. I don't need to read it, I want to see the commit history, PR reviews, and CI runs." Real shops have this. Vaporware shops do not.
2. "What's the last project you shipped that went badly, and what did you change?" Anyone claiming a spotless record is lying or new.
3. "Who owns the code, the infrastructure accounts, the domain, and the API keys on day one?" The correct answer is: you do, from the first commit.
4. "If I fire you in month three, what does the handover look like?" Should include repo access (already yours), env vars, runbooks, and a paid transition window.
5. "How do you estimate?" Look for: reference-class forecasting, spikes on unknown parts, explicit uncertainty ranges. Not: "gut feel from 20 years of experience."
6. "What happens when the LLM/API/third-party you're depending on breaks?" In 2026 half of custom systems have an OpenAI, Anthropic, or Google dependency. If they can't describe fallback, retry, and cost-cap behavior, they haven't shipped one to production.
7. "What's your bus factor on my project?" If one person leaving kills the build, you are the risk holder.

A useful pattern: send these in writing before the call. Vendors who answer in writing, in detail, are the ones you want. Vendors who insist on "discussing it live" are managing perception.

The AI question: what changed and what didn't

Every bespoke software company in 2026 will pitch AI. Most of the pitches are noise. Two things genuinely changed:

What changed: The cost floor for a working custom system dropped. A senior engineer with Claude Code, a decent test harness, and a real spec can now ship what took a 3-person team six weeks in 2022. That means a competent solo builder or a 2-4 person shop can deliver at prices that used to require offshoring, and with quality that used to require a senior in-house team. If a 40-person agency is quoting you $180k for a workflow tool, ask what specifically justifies the headcount overhead.

What didn't change: Requirements gathering, integration edge cases, domain modeling, and change management. LLMs don't help with the hard part, which is figuring out what to build and how the business actually works. Anyone who tells you "AI writes 80% of the code so we're 80% cheaper" is either lying about the percentage, the discount, or the quality.

A quick sanity check: ask the vendor to describe their eval harness. If they build LLM features without one, they are shipping code that works on the demo and fails in production. A minimum viable eval looks like this:

# eval_extraction.py — run on every PR
import json
from pathlib import Path
from your_app.extractor import extract_invoice_fields

def test_extraction_accuracy():
    cases = json.loads(Path("evals/invoices.json").read_text())
    passed = 0
    for case in cases:
        result = extract_invoice_fields(case["input"])
        if result == case["expected"]:
            passed += 1
    accuracy = passed / len(cases)
    assert accuracy >= 0.92, f"Regression: {accuracy:.2%} < 92%"

Twenty lines. Runs in CI. Catches the model change that would otherwise show up as an angry customer email. If your vendor doesn't have something equivalent, they don't take LLM reliability seriously.

How BizFlowAI approaches this

We build bespoke automation and internal tools for solopreneurs and teams under 10 people — mostly workflow systems, LLM-backed extraction pipelines, and custom CRM/ops glue. The team is small on purpose: the person who scopes your project is the person who writes the code and stays on for the handover. We work in fixed-price for narrow spikes and capped time-and-materials for anything larger, and every project starts with a paid discovery week that produces a scope doc specific enough to argue with.

The AI piece is not a marketing layer. We use Claude Code and a small set of internal agents to move faster on the parts that are genuinely repetitive — scaffolding, migration scripts, test generation — while keeping a human on architecture, integrations, and evals. The result is that a build which would have needed a 4-person shop in 2022 is often a 6-8 week engagement now, at a fraction of the price, with the same production discipline: your repo, your infra, monitoring on day one, and a runbook you can hand to your next engineer.

A decision checklist you can actually use

Before signing anything, print this and answer honestly:

• I have talked to the engineer who will lead the build, not just sales
• The proposal has explicit exclusions and a written change process
• I own the repo, infra accounts, domain, and API keys from day one
• There is a paid discovery / spike phase before the full commitment
• I have contacted at least two past clients and asked what went wrong
• The contract has a defined exit clause and handover process
• Monitoring, backups, and incident response are named in scope
• For LLM features: there is a written eval + cost-cap strategy
• The vendor said "no" to at least one thing I asked for
• I can articulate, in one sentence, why this vendor over the others

If you cannot check seven of these, do not sign yet. Push back or move on. The cost of another two weeks of vendor conversations is trivial compared to the cost of a stalled six-month build.

Choosing a bespoke software company is mostly about filtering out theater. The good ones show their work early, disagree with you productively, and quote what they can defend. The bad ones talk about partnership, transformation, and their proprietary methodology. Pick accordingly.

Work with BizFlowAI

If you'd rather have this built for you, that's what we do: production AI automation for solo founders and small teams — agents, integrations, and document pipelines that actually ship.

Book a free discovery call — 30 minutes, we map the highest-ROI automation in your workflow. No pitch deck, just engineering.

More guides like this on the BizFlowAI blog.