How to Choose a Custom Software Development Partner

Most custom software disasters aren't caused by bad code. They're caused by a buyer who couldn't evaluate a seller — because the buyer builds software once, and the seller sells it every week. This guide levels that asymmetry: the questions that expose weak vendors, the proposal red flags, and the honest version of the local-vs-offshore question.

It's part of our custom software hub, and yes, we're a vendor writing a vendor-selection guide — every test below is one we're content to be judged by.

Questions to Ask Before You Sign

"Who, by name, will write the code?" The single highest-signal question. If the answer is a "delivery team" you'll never meet, your project will pass through translation layers — salesperson to analyst to team lead to developers — and every layer loses fidelity. (Our answer: Michael Larsen, the founder. Everything in-house, no exceptions.)

"What have you built for yourselves?" A firm that ships and operates its own products has debugged its own decisions at its own expense. A firm that only bills hours has debugged nothing it had to live with. Ask for something you can actually use — ours is Tonalyzer, with the build story published.

"What's the stack, and why?" You don't need to evaluate the answer technically; you need to see whether one exists. "We use modern technologies" means the stack is whoever's on the bench. A real answer names tools and reasons — ours is on the custom web apps page, in writing.

"What happens when you're wrong about the estimate?" Every honest developer is sometimes wrong. The good ones have a structural answer (ours: a 20% buffer built into every estimate before quoting, so the signed number holds). The bad ones have never been asked.

"Walk me through a project that went badly." Refusal to name one is the red flag. Every experienced firm has scars; what you're evaluating is whether they learned process from them.

"Where do data migration and post-launch support appear in this quote?" The two most-omitted line items in lowball proposals, and the two most expensive to discover later. Their absence explains a suspicious total faster than any other check — the full pricing anatomy is in what custom software actually costs.

Red Flags in Outsourcing Proposals

Patterns that recur in the proposals we're shown during rescue projects:

• A total with no itemized scope. The scope lives in the vendor's head, where it can shrink while the price doesn't.
• "Yes" to everything. A partner who pushes back on your feature list in the first meeting is protecting your budget; one who agrees to all of it is planning to bill the corrections. Scope discipline is a service, not an obstacle.
• No working-software milestones. Payment schedules tied to dates rather than demonstrable software mean you can be six months and five figures in with nothing to click. We deliver working software continuously — you should accept nothing less from anyone.
• Vague IP terms. "You'll have full access" is not "you own the code." Get source code, documentation, and IP transfer explicit in the contract. (Ours: you own it, contractually, full stop.)
• The team you met isn't the team you get. Enterprise-polish sales calls followed by handoff to strangers is the defining move of the body-shop model.
• Hosting and accounts in the vendor's name. Your software living in someone else's cloud account is a hostage situation with monthly invoices. Everything should be in accounts you control.

Why Local Matters More Than People Think

The honest version, not the flag-waving version:

Where offshore genuinely wins: well-specified, self-contained work — a defined API, a batch of screens from finished designs — where the requirements fit in a document and real-time collaboration isn't needed. The hourly savings are real there.

Where local wins, and why the gap is bigger than it looks: custom business software is mostly requirements discovery — understanding how your operation actually works, which no document fully captures. That takes conversations, site context, and rapid iteration, which is precisely what twelve time zones and a translation layer destroy. The lowball quote prices the code; the communication overhead, revision cycles, and "finished but unusable" risk arrive later, unpriced.

There's also an accountability asymmetry nobody puts in proposals: a local firm's reputation lives where you can reach it — in our case, in the same metro market we publish our pricing for. A vendor whose next client will never meet you is spending different reputation than one whose next client might be your neighbor.

The hybrid trap: the "local firm" that's actually a sales office atop offshore delivery — you pay local rates and absorb offshore overhead. The "who writes the code" question exposes this in one sentence.

The Reference Call Nobody Makes

One underused tool deserves its own section: actually calling a vendor's past clients — and asking the questions that produce information rather than testimonials. Skip "were you happy?" (everyone says yes to that) and ask: What went wrong, and how did they handle it? (every project has a wrong; the handling is the data). What did the final cost look like against the original quote? (the single most predictive answer you'll get). Who did you actually interact with week to week? (tests the who-writes-the-code answer against reality). Would you use them for your next project — and are you? (the present tense is the tell). Twenty minutes of this beats any portfolio review, and a vendor who hesitates to provide reference contacts has answered early. We provide them on request, along with a build you can simply use yourself — the reference that can't be coached.

FAQ

How do I choose a custom software development company?

Run the six questions above and compare itemized scopes across bidders. Any vendor that fails the "who writes the code" or "what have you built yourselves" questions has answered everything you need.

Should company size matter in the choice?

Match the vendor's size to the project's coordination needs, not its importance. A focused small-business build is better served by a small senior team than a large firm — fewer layers, no bench-juniors learning on your invoice. Large firms earn their overhead on projects needing twenty coordinated people; hiring one for a two-person project buys the overhead without the need. The failure mode in both directions is mismatch, not size itself.

Are the cheapest quotes always a mistake?

No — for well-specified, contained work, a low quote can be rational. For discovery-heavy business software, a quote far below the field usually means the scope is missing organs (migration, integration error handling, support), and you'll buy them separately at distress prices.

What should the payment structure look like?

A deposit against a signed Statement of Work (ours is 50%), then milestones tied to working software you can use. Never fully prepaid; never date-based milestones with nothing demonstrable attached.

Does the developer need to be in my industry?

Helpful, not decisive. Engineering discipline transfers across industries; what doesn't transfer is willingness to learn your operation — which is exactly what the requirements-discovery conversations test in the first week.

How many bids should we get?

Three is the sweet spot — enough to triangulate scope differences, few enough to compare properly with the worksheet approach. Ten bids optimizes for procurement theater; one bid optimizes for regret. And weight the scope conversations over the documents: the vendor who asked the best questions before quoting usually builds the best software after.

What if we've already been burned once?

You're the majority of our inquiries, honestly. Bring the wreckage — code, contracts, whatever exists — and start with an audit rather than a rebuild pitch. Sometimes the failed project is 70% salvageable; sometimes it's evidence for the insurance conversation. Either way, the second vendor selection goes better armed with the first one's autopsy.

---

Evaluating vendors right now? Send us the proposals you're comparing — genuinely. We'll tell you what's missing from each scope, including where ours would be the wrong fit. Get a second opinion.