Build, buy, or fix what you have

Why is this a three-way decision and not a two-way one?

Because the third option exists and nobody's business model involves selling it to you. Software vendors sell buying. Development shops sell building. Consultants are paid for projects, and "keep what you have and fix four things about it" is not a project. Fixing is the cheapest, fastest and most reversible of the three, and it is the one you will have to raise yourself.

I think most software evaluations in this size band start about two years early and get pointed at the wrong question. The question in the room is which system to buy. The question worth answering first is what specifically the current arrangement can no longer do, said in one sentence, out loud, by the person who runs it.

If nobody can finish that sentence, no vendor demo will help. You will buy the system that gave the best demo.

Are the ERP statistics everyone quotes actually about your business?

Almost certainly not. Panorama Consulting Group's 2026 ERP Report, which most of the circulating numbers come from, surveyed 170 organizations between January 2025 and January 2026. The median respondent had annual revenue of $200.5 million and 56.5% of them were multinational. Its headline nine-month median project timeline describes companies with a full-time IT department and a change budget.

That is not a criticism of the report. It is careful work and I am citing it three times in this post. It is a warning about who it describes. If you run 200 staff in one country, and the closest thing you have to an IT department is a nephew who is good with computers, nine months is not your number and nobody knows what your number is.

The vendor quoting you that nine months has read the same report. Ask which line of it you resemble.

When should you buy?

When the failure is structural and your requirement is the same as everyone else's. One record several branches have to share. An audit trail you are legally required to produce. Payroll. Statutory filing. Buy when thousands of businesses need exactly what you need, because somebody has already built it better than you will, and they will still be maintaining it after you have stopped thinking about it.

There is a clean test for this. Describe what you need out loud without naming your company, your industry or any person who works there. If the description survives, the requirement is generic and you should buy it. If every second sentence is "but for us," you are describing something else.

Buying is not the mistake. Buying before you can say what the old way could not do is the mistake, and it is the one that produces the abandoned implementation sitting in your history right now.

When should you build?

When the process is the one thing you do differently from your competitors and that difference is why customers choose you. That is rarer than it sounds. Most of what feels distinctive about a family business is the relationships, the pricing judgment and the willingness to answer the phone at nine on a Sunday, none of which is a process you can build. Build the part that is genuinely yours. Buy or fix everything around it.

The arithmetic has moved. In McKinsey's State of AI 2026 survey, 32% of respondents said their organizations had decided against buying at least one software product or feature because they could build it internally with agentic coding tools. That is a real shift and it would be dishonest to pretend otherwise. Things that were quotes are now afternoons.

The build was never the expensive part though. The expensive part is month fourteen, when the person who wrote it has moved on, the one document explaining it is out of date, and a rule that made sense in March now quietly needs changing. You are then back where you started, except the thing nobody understands is now load-bearing.

Building is a permanent staffing decision wearing the costume of a one-time cost. If you cannot name who changes it next year, you are not choosing to build. You are choosing to have something you cannot change.

When should you fix what you have?

When the process is sound and only the record of it has broken. The signs are specific rather than general. Your people know exactly what to do, they just cannot prove afterwards that they did it. The information exists somewhere in the building, it is simply not in front of the person making the decision. There is a workaround, it works, and it costs four hours a week.

Nothing structural has failed in any of those. The delivery still gets made. The customer still gets the right stock. What broke is naming, or ownership, or timing: three things you can change without buying anything.

This is the most common case in businesses of this size and it is the one least likely to be diagnosed correctly, because the people you would naturally ask are all paid to tell you something else.

What does fixing actually involve?

Not trying harder, and not a new policy nobody reads. Four concrete moves, roughly in this order. None of them is software and all of them are reversible, which is the whole argument for doing them first.

• ·Replace free text with a controlled list. Where anyone can type a customer, an item or a unit, they will eventually type it three ways, and every report after that is an interpretation.
• ·Give every record one owner. Not one department. One person, by name, who decides what the number is when two people disagree.
• ·Write the procedure down, including the exceptions. The exceptions are the part that matters, because they are the reason the process currently cannot leave the head it lives in.
• ·Remove one re-key. Just one. Find the place where somebody types information that already exists somewhere else, and close that gap. It reduces the labor and the error rate at the same time.

Why do these projects fail when they fail?

Not for technical reasons. In the 2026 ERP Report, the most common cause of budget overruns was the unexpected need for additional technology, which Panorama attributes to poor system selection: organizations discover fatal misfits late in the project. The most common cause of schedule overruns was organizational issues, meaning governance, resistance to change and process redesign. Fewer than a quarter of organizations reported an intense focus on change management.

Read those three findings together and they say one thing. The project failed at a decision taken before the project started.

A fatal misfit discovered late is a requirement nobody had written down early. Process redesign appearing as a schedule overrun means the process was being designed during the implementation, which is the most expensive possible moment to do it. Neither is a software problem, and neither gets fixed by choosing a different vendor.

How do you tell which one you are?

Match the symptom, not the ambition. Most businesses in this band have one or two of these, not all of them, and the right answer is usually smaller than the one being discussed.

• ·Several locations keep separate copies of the same record and argue at month-end: buy. This is structural and it is the clearest case for real software.
• ·You are required to produce an audit trail you cannot currently produce: buy, but scope it to where money or stock moves, not across the whole business.
• ·The process is how you win work and no product does it your way: build, and name the person who maintains it before you start.
• ·The same customer is spelled four ways and two people produce two totals from one file: fix. A controlled list solves most of this in an afternoon.
• ·Everyone knows what to do but nobody can prove it happened: fix. This is a recording problem, not a capability problem.
• ·One person leaving would stop you invoicing, ordering or paying staff: fix, and fix this one first. It costs nothing to start and has nothing to do with technology.

What has to be true before you choose any of them?

One number, and almost nobody has it: what the current way costs per year, in hours and in errors. Without it every option looks equally reasonable, the decision gets made on confidence rather than evidence, and the most confident person in the room is usually the one selling something.

Counting it is a week of unglamorous work and it changes the conversation completely. A process costing fifteen thousand a year is one to leave alone. A process costing a hundred and forty thousand is a business case, and you can go and get quotes already knowing what a sensible one looks like.

It also fixes the order, which is the part most businesses get backwards. Find where the work actually leaks, fix and document the process, then automate what is left of it. A system can and usually should end up automated. It just cannot start there. Automating a process nobody has written down does not remove the problem, it makes the same problem run faster, somewhere you can no longer watch it happen.

Common questions

Sources

• Panorama Consulting Group, The 2026 ERP Report. 170 respondents, collected January 2025 to January 2026. Median annual revenue $200.5 million, 56.5% multinational, nine-month median project timeline. More than a quarter over budget, almost a quarter over schedule, fewer than a quarter reporting an intense focus on change management.
• McKinsey, The state of AI in 2026: On the road to ROI. 32% of respondents said their organizations had decided against buying at least one software product or feature because it could be built internally with agentic coding tools. Online survey of 1,719 participants in 97 nations, in the field 4 May to 8 June 2026, published 25 August 2026; responses are weighted by each nation's share of global GDP. Checked against the report, 6 October 2026.