How to buy custom software without getting burned

Every company that buys custom software is making one bet: that the people who showed up to the sales call are the people who will still be there when something breaks at 5pm on a Friday.

Most horror stories trace back to that bet going wrong. The rebuild eighteen months in. The agency that stopped replying after the final invoice. The "platform" that turned out to be a template with your logo on it.

You cannot remove the risk. You can make it visible before you sign. Here is how we would buy, if we were on your side of the table.

Ask who actually writes the code

Not "how big is your team." Ask for names, and ask whether those specific people will be on your project.

Agencies that sell with senior staff and deliver with juniors are not rare — it is close to a business model. The tell is simple: if the person who architects the system is not on the sales call, ask why not. A good answer exists. A vague one is the answer.

Ask to see something running

Screenshots are cheap. Case study PDFs are cheaper. What is expensive — and therefore meaningful — is a system in production that you can touch.

Ask for a URL you can click, a number you can call, or a screen recording of a real workflow with the data blurred out. If nothing they have built is available to look at in any form, you are being asked to believe a description.

Ask what broke on their last project

This is the question that sorts people fastest.

Every real system has a bad week. The data import that surfaced four thousand duplicate contacts. The integration that hit a rate limit nobody documented. The feature that shipped and nobody used.

Someone who has actually shipped will tell you the story, usually with some relish, because fixing it is the part they are proud of. Someone who says "honestly, nothing major" is either new or managing you. Neither is what you want.

A timeline promised before discovery is not confidence. It is a template.

Ask who owns the code on day one

The only acceptable answer is: you do. All of it, from the first commit, in a repository you control.

Watch for softer versions that sound like agreement — "you own your data," "you get a license," "we hand over at the end of the engagement." Those are not the same thing. Ownership that begins at handover is leverage held over you until handover happens.

While you are there, ask where it is hosted and whose name is on the account. Plenty of teams "own" software they cannot actually deploy without calling someone.

Ask what month four looks like

If support is a line item on a later slide, or a retainer to be renegotiated after the build, then launch is where the relationship is designed to end. That is a legitimate way to sell software. It is a poor way to buy the system your operations depend on.

The version you want sounds boring: someone monitors it, someone fixes it, someone extends it as the business changes, and you know that person's name.

The clause that matters more than the price

Milestone billing, tied to working software, with repository access from the first milestone.

Not tied to documents. Not tied to a phase that produces a slide deck. Tied to something you can open and use, however small, that gets bigger every few weeks.

This one clause does more work than any contract language about deliverables, because it makes progress impossible to fake. If a builder resists it, they have told you — politely, and in advance — how the engagement is likely to end.

What good looks like

You will know you are talking to the right team when the conversation gets less exciting rather than more. Fewer possibilities, more specifics. Fewer superlatives, more questions about how your team actually works today.

And at least once, they should tell you not to build something. Every operation has a process where the honest answer is a spreadsheet, an existing tool, or leaving it alone another year. A partner who never says that is not assessing your business. They are quoting it.

the-buyers-checklistlive