How to choose a software development partner — and the red flags to run from

About a third of our engagements start with a rescue: a stalled build, a codebase held hostage, an invoice pile with no product attached. The pattern behind almost every one of those stories was visible in the first two sales conversations — the client just didn't know what to look for. This is the checklist we wish every buyer had, including the parts that occasionally cost us a deal.

Green flags

• They ask about your business before your requirements. A partner who wants your P&L context, your workflow, and your definition of success is pricing an outcome. One who jumps straight to features is pricing their time.
• Working software on a weekly cadence. Demos of the actual product every week — not status decks — are the single strongest predictor of a healthy project.
• Small senior teams with names. You should know who is writing your code and be able to talk to them directly.
• Billing aligned with outcomes. A vendor whose payment depends on delivering — not on hours elapsing — has done real scoping and carries the risk themselves. 'We bill hourly and see where it goes' means the risk is all yours.
• References from businesses your size. A portfolio of Fortune 500 logos is irrelevant to a 40-person company; ask to talk to a client shaped like you.
• They tell you 'no.' Somewhere in the sales process, a good partner should talk you out of something — a feature, a scope, sometimes the whole project.

Red flags

• You can't get your data out. Whatever the code arrangement — you own it, or you subscribe to software the vendor hosts and maintains — your business data must be yours and exportable on demand. If you can't walk away with your data, you're negotiating a hostage release later.
• A price that's dramatically below every other quote. Someone is planning to make it up in change orders, or planning to fail cheaply.
• No staging access. If you can only see the product when they choose to show it, you'll discover the truth at the deadline.
• The pyramid. You meet two impressive seniors in sales; the work is done by rotating juniors you never meet. Ask directly who writes the code.
• Yes to everything. A vendor with no pushback on scope, timeline, or budget hasn't understood the project — or doesn't intend to honor any of the three.
• Vague answers about what happens after launch. 'We can discuss maintenance later' translates to emergency-rate invoices in year two.

Seven questions to ask every vendor

• Who exactly will write our code, and can we meet them before signing?
• What's excluded from this quote, and what happens if the work runs over?
• How often do we see working software, and where?
• Can I export my data and walk away at any time?
• What does a typical month cost after launch?
• Tell me about a project that went wrong. What did you do?
• Can I speak to a client of roughly our size from the last year?

How to compare the finalists

Don't compare prices; compare answers. Take your two or three finalists, ask all seven questions, and put the responses side by side. The differences will be starker than the dollar figures — and far more predictive. A vendor with clean answers and a higher number is almost always cheaper than a vendor with vague answers and a lower one, because the vague vendor's real price hasn't been revealed yet.