I recently saw a post that argued that IT technical debt is not necessarily always a bad thing, and I think in general that rule is probably correct. Here’s where sometimes it is not.
Our discovery calls are always a fun process, and we always learn things we need to know in them. This particular story was no different. A mid-market growth company that pulled in pretty healthy revenue last year. They had a solid footprint in traditional distribution, but leadership wanted to expand into other channels, and to do that, they needed their ERP (and realistically the rest of the tech stack) to talk to the modern world.
But when we looked under the hood, we realized their ERP was about 14 versions out of date. Not minor patches, I’m talking fourteen biannual, cornerstone releases missed. They weren’t just missing features; they were operating with massive security vulnerabilities, outdated workflows, and technical processes that did not match the core functions of anything they really needed to integrate with. No modern integrations existed for their version, so they were fundamentally cut off from connecting it to anything else.
When asked how they had survived this long, their answer was “our internal team has written code for pretty much every process to make things work; when the business needs a workaround, we’ve delivered, but we know there is a better way.” Which is good to hear because that custom development trap can break any growth company if not managed to the nth degree – at least in the long term. Even in mature enterprises, this can be problematic over the long term when custom solutions are used instead of off-the-shelf tooling. Particularly if there is the capability to adopt a composable platform architecture model rather than a monolithic one. Something that I expect we will dive into at a later date!
Now, in and of itself, custom code is not a bad thing; even fully custom systems can have their place. But only with rigorous review, planning, and a full understanding of the total cost of ownership. Because while the initial cost can look manageable, things tend to spiral out of control fast, particularly when it comes to supportability, cybersecurity, and overall Total Cost of Ownership (and sometimes even Total Feature Deployment).
When you custom-code standard business applications, you create two wildly diverging points that ideally should be much closer together
- Total Cost of Ownership (TCO)
- Agility and Market Competitiveness plummet straight down.
Every time a connect system vendor pushes an update or makes even the smallest change, stuff breaks, even with COTS systems. Add custom code into the mix and stuff spirals out of control, and as other companies move faster your ability to respond to changes in the market usually diminishes unless you are spending lots of time on continuous improvement and upkeep. If you are not, the solution isn’t as simple as running a patch. To fix it, you need to pay engineers thousands of dollars just to dig themselves out of the hole they dug the year before.
Then suddenly, you are seven years in and a full ERP replacement lands on the table with a price tag between $300,000 and $700,000. Even a lightweight, bare-minimum fix is $250,000, and just evaluating the wreckage costs a minimum of $20,000.
Every platform has ongoing maintenance, infrastructure, and upgrade costs. The problem is, too many projects – particularly ones that have heavy custom integration are only measured on the day zero/one cost of the project, plus directly attributable ongoing costs in terms of infrastructure/licenses (sometimes). Realistically, to truly get to a calculation of both real TCO and real ROI, you need to factor in the bigger picture – and you might have to make some educated guesses on costs too. The simple fact of the matter is, the more custom code in a system or platform, the more you are diverging from a known workable practice and the more likely you are to incur technical debt at a faster rate. That may be the right decision at that point in time, or for a ton of other reasons, but you do need to approach it with your eyes wide open.
But regardless of what decision was made in the past and whether things were heavily customized or not…. when it comes time to upgrade, improve, or change… now how do we get the budget approved and show our stakeholders this spend is justifiable. Because too many projects either don’t paint the whole picture, or never really look at it, and they end up being one of those 95% of failed AI pilots from last year!
So, how do you get an exec board to approve a mid-six-digit technical debt remediation project when they can’t “see” the immediate profit?
You stop treating IT as a cost center and start modeling it as a risk-and-value engine.
One of the most effective ways to do this is to adapt the FAIR (Factor Analysis of Information Risk) framework, which is traditionally used for cybersecurity risk, and apply it directly to new tech investments. The FAIR approach forces you to mathematically weigh the financial impact of your current state against your future state, including much of the impact of any current or future risks actually being realized. That’s infinitely more sophisticated than looking at a simple payback period.
1. Quantify the cost of “doing nothing”
Under FAIR, you calculate the loss exposure of staying on an outdated system. What’s the statistically probable cost of a catastrophic security breach on a system 14 versions behind? How about the daily cost of not being able to launch the new consumer distribution channel?
2. Measure true throughput gains (not headcount)
A major trap in some traditional digital transformation is assuming ROI comes from cutting headcount. Industry research consistently shows that reducing staff rarely delivers true transformation value, and there’s a great one on the AI equivalent of this from Gartner. Instead, look at throughput improvements and labor optimization. For example, in highly regulated manufacturing spaces, moving from manual document routing to automated electronic validation saves 24+ hours per compliance document. Multiply that across thousands of products and systems, and the labor savings translate into massive, defensible external contractor or engineering hours saved.
3. Factor in the user adoption risk
On paper, an ERP or other technology systems can show incredible ROI. But if your internal champions aren’t enabled, and the workers on the warehouse floor (or plant floor or office floor) reject the change, your realized ROI is zero or even negative. A good financial model accounts for change management as a core variable for the project, ensuring training and adoption are funded as heavily as the code itself.
So here is the thing. The era of custom-coding your core operational workflows is over, and AI shouldn’t change that at a mid-market or enterprise level.
Commercial off-the-shelf systems and modern platforms require significantly less consulting time to deploy than they did five years ago. The time-to-value has dropped dramatically because the core platforms have gotten better. If your internal IT team’s first instinct is to vibe-code to solve a standard business software limitation, pause. They’re solving a problem today, but it’s writing a six-figure check for technical debt that your company will have to cash tomorrow.
So over and done, my first newsletter! I hope that this concept of “Before the Stack” is something that sticks. Ideally, this will be a newsletter for leaders navigating digital transformation, particularly in life sciences, who are tired of technology being sold as the solution before the problem is properly defined.
Ideally, this, to a large degree, will be about getting back to the fundamentals: telling through stories how to build a transformation strategy that leads with people, structures itself around process, earns its ROI before the first platform goes live, and treats compliance not as a barrier but as a backbone. Because the most expensive mistake in digital transformation isn’t choosing the wrong software, it’s choosing software before you are ready. Most digital transformation initiatives start in the wrong place. They begin with a platform demo, a vendor pitch, or a technology roadmap, and somewhere along the way, the humans, the workflows, the data quality, and the regulatory requirements get treated as implementation details rather than foundational decisions.
Before the Stack exists to change that conversation. My firm has deep roots in life sciences, and careers spent helping organizations get transformation right; this newsletter is for the executives, operators, and change leaders who want to understand not just what to implement, but in what order and why it matters.
The thesis is simple: People come first. Then process. Then data. Then, and only then, technology. Layer compliance throughout, and measure everything against real ROI.
It sounds obvious. Very few organizations actually do it. Before the Stack is where thought leadership meets practical accountability; for life sciences, and for anyone who believes that lasting digital transformation is less about the tools you buy and more about the discipline you build before you buy them.
To follow this newsletter on LinkedIn please go here: https://www.linkedin.com/newsletters/before-the-stack-7481015489201119232/
