Build vs buy: internal tools for a growing trade firm

At some point a growing firm hits a job its software cannot do, and someone says "we should just build our own". Sometimes they are right. Usually they are about to spend two years learning why software companies exist. Here is how to make the call with your eyes open.

The question behind the question

Build versus buy is really a question about differentiation. Every process in your firm is either a commodity, something every firm does roughly the same way, or a differentiator, something you do differently and better, where the difference wins you work or margin. Payroll is a commodity. Your particular way of pricing, following up, or running jobs might be a differentiator.

The rule that falls out of this is old and still correct: buy commodities, invest in differentiators. Building your own commodity tool means paying full price to reinvent something you could rent finished. Buying a generic tool for your differentiator means sanding off the very edge that makes you money.

The real cost of building

The build estimate you have in your head is the cost of version one. The real cost is everything after:

A common rule of thumb in software is that building version one is a third or less of the lifetime cost. For a trade firm without in-house developers, the ratio is worse, because every fix is an external invoice or a weekend. None of this means never build. It means the quadrant where building pays is small, and honesty about which quadrant you are in is worth thousands.

The real cost of buying

Buying has quieter costs, which is why it usually still wins for commodities. Subscriptions compound: a stack of tools at per-seat prices adds up to a permanent tax. Generic tools force process compromises, and the workarounds have a cost in hours. And the gaps between bought tools become your problem: the retyping between the CRM, the accounts package and the job sheets is unpaid integration work done by your staff daily. We cover that failure pattern in spreadsheets vs estimating software and connecting your business software.

The third option: custom-installed on top of what you buy

The binary framing hides the option most growing trade firms actually need. You do not have to choose between renting generic software and becoming an accidental software company. The middle path is a custom-installed system: bought tools for the commodities, and a custom layer built around your differentiating processes, wired into those tools.

This is the model AGMM operates. The buy side stays bought: your CRM, email and accounting package remain the products they are. The build side is scoped tightly to what differentiates you, and, critically, someone else owns the maintenance, the integrations and the breakages. The install follows a fixed rhythm: onboarding in week one, build and configuration in week two, integration with CRM, email, accounting, project management, internal databases and third-party software in week three, testing and pilot in week four, go-live in month two, an optimisation review in month three and expansion in month four. Onboarding costs £2,000 to £10,000 by scope, plus ten percent of the value created, tracked in your own CRM, so the ongoing cost scales with results rather than with seats. The structure is described in full on the QS Quoter Commercial page.

Compared with building in-house, you skip the bus factor and the maintenance trap. Compared with pure buying, your differentiating process keeps its edge instead of being flattened into a template.

A worked decision path

1. Name the process that your current tools cannot handle, in one sentence with a number in it.
2. Apply the differentiation test. Commodity? Buy, and stop here.
3. Check stability. If the process is still changing monthly, run it on flexible generic tools until it settles. Building on quicksand wastes money.
4. Price all three honestly: lifetime cost of building (times three on your estimate), the compromise cost of buying, and a custom install with its value share.
5. Whatever you choose, pilot before you commit the firm to it, as argued in the month-one playbook.

Most firms that run this path end up buying more boring software than their instincts wanted, and investing properly in the one or two processes that actually make them different. That is usually the right answer.

And if the path ends at "do nothing for now", take that seriously too. A tool problem that cannot be stated with a number attached is often not yet a tool problem at all, and the cheapest option is to keep running on what you have while the process settles enough to be worth investing in.