For years the internal operations of this firm — time, staffing, project budgets, the machinery that turns billable work into invoices — ran on a commercial platform built for professional-services firms. It did the job until it didn’t. As the way we staff and run engagements evolved, the software stopped fitting, and we arrived at exactly the crossroads we walk clients through every week: renew the thing that no longer fits, buy a bigger replacement, or build what we actually need.
We built it. It is called IRMA, and it now runs our resource management, timekeeping, staffing plans, and project financials end to end. Living through that decision from the inside sharpened our own advice more than any client engagement could have.
The decision we advise on, faced from the other chair
The build-versus-buy conversation is easy to have in the abstract and hard to have honestly when it is your own money and your own operations on the line. We felt every pull we warn clients about.
The pull to renew, because switching is disruptive and the incumbent is familiar. The pull to buy something large and well-known, because a recognizable name feels safer than a decision you have to defend yourself. And the pull we usually have to argue for on behalf of clients — to build precisely what the work requires — which from the inside feels like the riskiest option right up until you scope it honestly.
Scoping it honestly is what changed the picture. When we wrote down what we actually needed rather than what our old platform did, the requirement was smaller and sharper than the market’s off-the-shelf answers, and most of the “features” we thought we would miss turned out to be workarounds we had built around the old system’s limits. That is the same discovery we watch governments make when they start at zero — the current system is not the requirement, it is one dated answer to it.
What building IRMA taught us to tell clients
Three lessons came out of it that we now carry into the advice itself.
Requirements written from the work are dramatically smaller than requirements written from the incumbent. We had assumed our needs were large because our old platform was large. They were not. Most of the size was inherited habit. Agencies routinely make the same mistake and buy far more system than the work demands.
“Build” is not automatically the expensive, risky option. It is expensive and risky when the requirement is vague and the scope drifts. When the requirement is disciplined and derived from real work, building what you need can be the smaller, more controllable path — and you own the result outright, with no license clock and no roadmap that belongs to someone else.
Owning the software changes the relationship to it. IRMA does what our work needs because we can shape it to the work, not the other way around. That is the whole argument behind modernizing what you own rather than surrendering your process to a product’s assumptions — and it lands differently now that we live inside it.
The point is not the tool
IRMA is a tool for running our own firm; it is not a product we sell. We are telling this story because it is the clearest proof we can offer that the advice is not theoretical. We build software when the work calls for it — Caliber for the government ERP decisions we run with clients, IRMA for the operations we run ourselves. Both exist because we would rather own an instrument shaped to the work than rent one shaped to someone else’s.
When we tell a county that the honest answer to its ERP problem might be to modernize what it already owns, or to build a focused capability rather than buy a sprawling suite, that is not a position we hold at arm’s length. It is the decision we made about our own house.
If you are weighing renew, buy, or build for a system your organization has outgrown, schedule a briefing. We have been in that chair recently, and we will give you the honest version.