The “build it and they will come” mindset is quietly killing automation budgets. While executives often celebrate successful pilot programmes, the transition to enterprise-wide deployment frequently reveals a gaping hole in financial planning.
According to Greg Holmes, Field CTO for EMEA at Apptio (an IBM company), the disconnect between a pilot and production is often where innovation dies. In fact, nearly 80 percent of innovation projects fail, largely because the financial models used during the testing phase ignore the brutal realities of scaling.
The Pilot Illusion
It is easy to misinterpret early success. A pilot might demonstrate clear time savings—perhaps 100 hours a month—which looks like a victory on paper. However, these pilots often run on over-provisioned infrastructure that masks true efficiency data.
“You wouldn’t over-provision to that degree during a real production rollout,” Holmes notes. Once that workload hits production, the calculus changes entirely. API calls multiply, edge cases appear at volume, and support overheads balloon. If you haven’t accounted for these shifts, your “successful” project becomes a liability.
Shift from Reactive to Proactive
To fix this, technical leaders must shift from reactive cost management to proactive value engineering. Instead of waiting months to assess value, teams should track resource consumption—such as cost per transaction or API call—from day one.
This requires a focus on unit economics. If your cost per customer increases as your customer base grows, your business model is fundamentally flawed. True scaling should see these unit costs decrease. Holmes cites a strategy used by Liberty Mutual, which uncovered $2.5 million in savings by looking beyond simple labour hours and focusing on deep consumption metrics.
Empowering Developers with “Price Tags”
Financial accountability cannot sit solely with the CFO. It must be pushed left—directly into the hands of developers.
By integrating financial governance into infrastructure-as-code tools like Terraform and GitHub, organisations can enforce policies before deployment. This allows engineers to see the cost implications of spinning up resources in real-time. It eliminates the “whack-a-mole” approach of deploying code and trying to fix the budget later.
The Legacy Debt Trap
For founders dealing with legacy ERP systems, automation presents a binary choice: is it a patch, or is it a bridge to modernisation?
Automating an inefficient process without redesigning it is simply “building up more technical debt.” Leaders should use a Total Cost of Ownership (TCO) approach to assess whether a legacy system is worth saving. Sometimes, the cost of the “automation wrappers” required to keep an old system on life support exceeds the value of the system itself.
The Bottom Line
Successful scaling requires a common language between Finance and Engineering. By moving toward a standardized framework that translates technical inputs (compute, storage) into business outputs, founders can stop guessing where the budget went and start building sustainable, scalable automated systems.
