Is it worth building custom software for a 100-person construction company?

Build versus buy is usually argued as though the alternative to custom software is nothing, or a spreadsheet. At a hundred people it almost never is. By the time a contractor reaches that headcount there is already a stack, it is already being paid for every month, and the decision is not whether to spend money on software. It is what the money is currently buying.

That reframing matters because it changes which numbers you need. The question stops being whether you can afford to build and becomes what the current stack costs, in subscriptions and in the work that exists only because of it.

Before we built anything, Patriot Pipeline had BusyBusy for time tracking, Discord for internal communication, and several other per-seat tools alongside them. None of that was a mistake. Every one of those products is competent at what it does, and each was chosen for a real reason at the time.

They were also unhappy with it, which is a different complaint from "it is broken" and is the one worth taking seriously. Nothing had failed. The stack simply did not fit the company, and the misfit was being absorbed by people rather than reported by software.

Across 114 field employees, per-seat pricing multiplies. What multiplies with it is the portion of each product nobody opens. Every one of those tools ships a feature set aimed at the widest market it can reach, and an underground utility contractor uses a fraction of it. The unused fraction is not free. It is priced in, per head, per month, indefinitely.

Per-seat waste is the visible number and it is the smaller of the two problems. The larger one is that tools bought separately do not know about each other.

Time tracking does not know the schedule. The schedule does not know which equipment is on which job. Internal messaging knows neither. Every place two of those need to agree, a person is the integration, and that person does not appear on any invoice as a software cost. They appear as headcount.

This is why replacing several tools with one platform is not really a consolidation exercise, and why arguing it on subscription savings alone undersells it. The saving that matters is the work that existed only because the tools were separate.

There is a size below which off-the-shelf wins and nothing more needs saying. A ten-person contractor should buy a product and get on with the job. We are not going to publish a crossover headcount, because there is not one: it depends on how far your process sits from the product's assumptions, not on how many people you employ. Two contractors of the same size can sit on opposite sides of it.

The useful test is not whether you are big enough. It is two counts, and both are countable this week. How many hours does somebody spend moving information between systems that ought to already agree. And how much are you paying, per seat, for functionality nobody opens. Do that arithmetic before you call anyone, including us.

Two platforms, plus a suite of AI tools across office operations, all in live production. The field operations platform carries time tracking, scheduling, equipment tracking and internal messaging in one system, which is precisely where the seams used to be. The project financials platform carries estimating, cost tracking, budget tracking and the analytics behind invoicing and billing.

The case study has the full picture, including what each piece replaced.