Build, buy, or neither: choosing software for a building materials business

Buy when your problem is ordinary and a product already solves it. Build when the thing that makes you money is the thing no product models. And quite often, do neither — because the problem is a process nobody has written down, and software will simply make it more expensive.

That third option is the one nobody selling software mentions. It is also, in our experience, the right answer more often than the other two.

When should you buy?

When the process is standard, the rules come from outside your business, and being different offers you nothing.

• Accounting and statutory compliance. The rules are set by the government, not by you. Building this is a decision to maintain tax logic forever, for no advantage.
• Payroll. Same reasoning.
• Email, storage, communication. Obviously.
• Standard eCommerce, where your catalogue is not unusual and your fulfilment is conventional.

The test: if a competitor buying the same product would run their business identically, buy it. There is no advantage available, so pay the smallest amount for the least trouble.

When should you build?

When the process is genuinely specific to you, and doing it well is part of why customers choose you.

In building materials this is usually one of four things: a catalogue that packaged systems cannot represent, a channel structure that does not fit a standard hierarchy, scheme logic particular to your market, or a configuration and quotation process that determines your margin.

The honest test is harder than it sounds: can you name the specific thing no product does? Not “nothing quite fits” — the actual capability. If you cannot name it in a sentence, you are not ready to build, because the specification does not exist yet.

The second test: would you still want this in five years? Custom software is a commitment to maintenance. If the process might change entirely next year, building it now is expensive.

When is the answer neither?

More often than you would expect, and recognising it saves a great deal of money.

When nobody agrees what the process is. If three people describe the order approval differently, software will not resolve the disagreement — it will encode one version and the other two will work around it. Settle the process first, on paper. It costs nothing and it is the actual work.

When the real problem is a person. One overloaded coordinator, one unfilled role, one manager who will not delegate. Software does not fix organisational problems, it distributes them.

When the data does not exist yet. You cannot report on secondary sales you have never collected. Start collecting — even badly, even manually — and build the reporting once there is something to report on.

When the volume does not justify it. Forty orders a month is a spreadsheet and a shared folder. It becomes a system at some volume, and that volume is higher than most vendors suggest.

When it is being bought to look modern. If nobody can say what will be measurably different afterwards, nothing will be.

What about doing all three?

This is what most successful building materials businesses actually end up with, and it is a deliberate architecture rather than a failure to decide.

Layer	Approach	Why
Accounting, tax, payroll	Buy	Rules set externally, no advantage in differing
Catalogue, batch, slab, configuration	Build	Nothing packaged models it
Dealer portal and channel	Build or adapt	Depends how unusual your channel is
Messaging and communication	Buy	Platform-defined, changes constantly
Reporting	Build on top	The questions are yours

The cost of this approach is integration, and it is usually underestimated. Connecting four systems reliably is real work — but it is considerably less work than making one system do everything badly.

What should you do before deciding?

1. Write down the process as it happens today, including the workarounds. If you cannot, that is your answer for now.
2. Name what would be measurably different afterwards. A number, not a feeling.
3. Look at products first, properly. Demonstrate with your own awkward products, not their sample data.
4. Identify the specific gap between what products do and what you need. That gap is the build.
5. Ask what happens if you do nothing for another year. Sometimes that is genuinely fine.

We start engagements with roughly this exercise, and it occasionally ends with us recommending no project. That is a better outcome for both sides than building something nobody uses — see product design and discovery.

Common questions

Is building always more expensive?

Upfront, usually. Over several years it depends on licence costs, user counts and how much workaround labour a packaged system imposes. A cheap product that needs two people maintaining spreadsheets beside it is not cheap.

What about customising a packaged product?

A reasonable middle path, with one caution: heavy customisation makes upgrades painful, so you may trade a fit problem for an upgrade problem. Ask what happens at the next major version before committing.

How do we avoid building something nobody uses?

Involve the people who will use it before it is designed, not at training. Most unused software was specified by managers and given to staff, and the gap between those two views is where adoption dies.

Should we wait for a better product to appear?

If the problem is costing you real money now, waiting is a decision with a price. If it is an irritation rather than a cost, waiting is cheap and reasonable. Be honest about which one it is.

More on this: what to digitise first and choosing dealer management software. For how we work, see what we build.