Build vs buy vs hire: the option nobody offers

Every broken workflow attracts the same three suggestions. Buy software that promises to handle it. Hire a developer to build something in house. Or do neither, and keep absorbing the cost by hand. Those are the defaults for good reason. Most problems really do fit one of them. The trouble starts when a problem fits none of them, and you pick one anyway, because it was the only list you were handed.

Here is where each path earns its keep, where it quietly fails, and a fourth option that fits more often than people admit.

Buy, when it works

If a process is standard, runs the way it runs at most companies, and is not where you compete, buy the product. Payroll, accounting, email, scheduling. These are solved problems, and a good vendor keeps improving them on their budget, not yours. There is no sense rebuilding what you can rent for a few dollars a seat.

Buy, where it breaks

Buying breaks when the tool is built for the average of a thousand companies and your problem lives in the part that is specific to you. You pay for the 80% you already had, and you still cannot get the 20% you cannot operate without. The gap gets filled with a manual step, the manual step becomes permanent, and the cost moves from the software budget to payroll, where nobody is watching it. Add renewal increases and per seat math as you grow, and the cheap option stops being cheap.

Hire, when it works

Hiring a developer makes sense when you have a steady stream of work to keep them busy, an internal team that wants to own the software for the long term, and enough volume to justify the seat. If you are building a product rather than fixing a workflow, you need people on staff.

Hire, where it breaks

One internal hire cannot be the domain expert, the infrastructure engineer, the integration specialist, and the person who actually understands AI, all at once. The role can take months to fill before the first useful line of code ships. And the day that person leaves, the knowledge leaves with them, and the tool they built becomes the thing nobody else dares to touch.

Build it for your workflow

There is a fourth option that rarely makes the list: have the specific tool built for you, to a fixed scope and a fixed price, shaped around how your team actually works, and handed over so you own the result. This is not staffing. It is not a platform you have to configure into submission. It is software for the 20% the products miss, sitting on top of the systems you already keep.

Where building is the wrong call

It is only fair to say when this does not fit. If the problem is still vague, you are not ready to build, you are ready to define. If an off the shelf product genuinely covers the work, buy it and move on. And if no one on your side will own the result after handoff, fix that first, because a tool with no owner becomes another workaround.

The question underneath

The real decision was never build or buy in the abstract. It is which gap you are trying to close, and whether the path you choose closes that gap without opening a larger one. Name the workflow that is costing you, and the right approach usually picks itself.

The question is not build or buy. It is which gap you are actually closing.