Buy, build or engineer? A practical way to decide

There's no prize for building software you could have bought. Payroll, accounting, email and most of what every organisation does the same way are better bought: someone else carries the cost of keeping them current, and your process gains nothing by being different there.

The question is where your process is different, and whether that difference is worth keeping.

Buy when the process is generic

• The process is the same across your industry, and regulators or standards define it.
• You'd happily change how you work to match a well-designed product.
• It doesn't touch your customers in a way that sets you apart.

Engineer when the process is how you compete

• Your best people are working around the tools to deliver what customers value.
• The same customer passes through several products, and the handoffs are where things go wrong.
• Your rules change faster than a vendor's roadmap, and every change means a workaround.
• You need a record of decisions that no single product holds.

The hidden cost on both sides

Bought software's hidden cost is the work around it: rekeying, reconciling, and the spreadsheets that fill the gaps. Built software's hidden cost is ownership: someone has to keep it secure, tested and changing with the business. Either can be the right trade. The mistake is comparing one's licence fee with the other's build cost and ignoring both hidden costs.

A simple first step

List the processes where people work around your tools today, and estimate the hours each costs a week. The top one or two are your candidates. Everything else can probably stay bought.