Build vs. Buy, Without the Sales Deck

We build custom software for a living, and our honest answer is usually buy it. The interesting question is knowing which situations are the exception.

The default is buy

Payroll, email, ticketing, accounting, storage. These are solved, the vendors compete on price, and a custom version is a liability you pay for twice — once to build, forever to maintain. If your requirements fit an established category, buy the category leader and move on.

Three questions for the exceptions

1. Is this how you compete?

If the process is a source of advantage — the thing you do better than the people you lose deals to — then a tool that makes you work like everyone else is a downgrade. Build the part that is genuinely yours. Buy everything around it.

2. What does the workaround cost?

Count the shadow spreadsheets, the re-keying, the coordinator whose job exists because two systems do not talk. Multiply by loaded salary and a year. That number is the real budget, and it is usually larger than anyone expects because it was never on a line item.

3. Who owns the data model?

If a vendor decides what your core entities are, they also decide what questions you can ask about your own business, and what an exit costs. For a system at the center of operations, that constraint is worth more than a handful of features.

The answer is usually both

Most good architectures are bought at the edges and built in the middle. Buy the CRM, the warehouse, the auth provider. Build the workflow that actually reflects how your organization works, and integrate. That keeps the custom surface small enough to maintain and specific enough to matter.

If you do build

• Scope to one workflow, end to end — not one layer across five workflows.
• Ship to real users inside a quarter. Anything longer is a research project wearing a delivery costume.
• Write down what would make you kill it, before you start.
• Budget for the second year. Software that is used gets changed.