Most companies have a technology stack. Very few have one that compounds. The difference is not which tools you bought. It is whether the system was designed to get better by itself.
Most companies at your stage have a technology stack. Some have a good one. Very few have one that compounds.
The difference is not about which tools you bought. It is about what happens to the value those tools produce over time. In a typical stack, each tool does its job: your CRM stores contacts, your marketing automation sends emails, your analytics platform generates reports. Each tool depreciates. It gets older. It requires maintenance. It occasionally gets replaced by something newer. The value it produces is roughly constant, minus the cost of keeping it current.
A compounding stack behaves differently. Each component makes the other components more valuable over time. The data your CRM collects makes your marketing automation smarter. The patterns your marketing automation surfaces make your analytics platform more precise. The precision in your analytics makes every dollar of future spend more efficient. The system improves without anyone adding a new tool or increasing the budget.
I have built compounding stacks twice in my career. Once for a $17 million home improvement company that grew to close to $100 million over 14 years. Once for a $2 billion pest control company where a single system, PinID, generated more than $500 million in trackable revenue over a decade. In both cases, the stack was not a collection of tools. It was an architecture that treated every customer interaction as an input that made the next interaction better.
By the end of this issue, you will have a framework for evaluating whether your technology infrastructure compounds or depreciates. You will also know the three architectural conditions that separate the two, and what it takes to shift from one to the other.
The question you should be sitting with as you read: If your technology stack is a depreciating asset that requires increasing effort to maintain its current performance, what does that mean about every dollar you plan to spend on it next year?
The belief running through most $10M to $100M companies right now sounds like this: "We need to invest in our technology stack to stay competitive."
It is repeated in board decks, strategic plans, and budget requests. It is the consensus view. And it is hiding a question that almost no one asks: what kind of asset are you building when you invest? There are two kinds of technology infrastructure. Most companies are building the first kind and calling it the second.
A depreciating stack looks identical to a compounding one in year one. The divergence becomes visible at year three or four, and by then the compounding stack has a head start that budget cannot close.
A compounding stack has three properties. If any one is missing, the stack depreciates. If all three are present and connected, it compounds. There is no partial credit.
The following are composite examples drawn from engagements, market observation, and documented outcomes. Names and specifics are masked. The patterns are real.
A $42M B2B SaaS company spent roughly $1.2 million a year on twelve tools: CRM, marketing automation, ABM, intent data, sales engagement, a new AI content generator. Each did exactly what it was purchased to do.
Three years in, spend had risen to $1.8 million. Lead volume was flat. Conversion had not moved. The marketing team spent about 30% of its time exporting, cleaning, and re-importing data between tools. They called it "operating the stack." It was maintaining the depreciation. No tool made any other tool smarter, so nothing compounded.
A $28M professional services firm recognized the problem and commissioned a $400,000, six-month integration to unify CRM, marketing automation, and analytics. It worked. Conversion rose about 15%. Manual data work dropped.
But the integration was static. It moved the same data between the same three systems in the same patterns, day after day. When the firm bought an AI lead-scoring platform eight months later, it required a new integration: $180,000, four months. The marginal cost of adding capability never fell. That is the definition of a depreciating system.
The home services engagement referenced in last quarter's issue began from a worse position than either case above: $17 million in revenue, $160,000 a month in advertising, zero tracking, no closed loop of any kind. The difference was architectural intent from day one.
Every system was designed with all three properties in mind. Call tracking fed conversion data back into ad targeting. The website created a shared customer profile that the call center, sales, and marketing all read from and wrote to. Campaign performance went into the system that allocated the next dollar of spend, not into a dashboard. Ad spend dropped from $160,000 to about $60,000 a month while lead volume rose 160%, and the improvement compounded every month as the loop processed more data.
The difference between a depreciating stack and a compounding one is not determined by what you buy. It is determined by how you connect what you buy, and whether the connections are designed to learn. Three things most purchasing processes never evaluate:
The Terminix PinID system is the clearest example. Direct mail campaigns carried unique PIN codes that triggered personalized web experiences and real-time lead routing. Every interaction improved the next campaign's targeting, the next web experience, and the next lead's routing. It ran more than a decade and generated an estimated $500 million in trackable revenue, not because someone kept optimizing it, but because the architecture optimized itself. The compounding was structural, not operational. That system was built with technology that is primitive by today's standards. What has not changed is the requirement: someone has to design for compounding from the beginning. The tools cannot do that part.
Most CEOs who read this will recognize their stack in one of the three composites, and most will recognize it in the first two. That recognition is a starting point, not a problem. The decisions that produce a compounding stack can be made at any point. But every year you delay, the competitor with the compounding stack pulls further ahead, and the gap is not linear.
If the answer is "about the same," your stack is depreciating. If the answer is "we do not know," that is worse, because it means you are spending without measuring what kind of asset you are building. The companies that will dominate their markets over the next five years are not the ones spending the most on technology. They are the ones whose technology spending compounds.
Six voices. One compounding question. Real disagreement about what decides whether a stack appreciates or depreciates.
Where the panel landed: Eleanor argued the problem is purchasing architecture; Marcus, execution discipline; Nadia, that AI raises the ceiling but requires the foundation first; Stover, that accessibility is the real barrier; Linda placed it in historical context and called the transition inevitable; John argued the bottleneck is organizational willingness to protect the loop. They agreed on one thing: most companies at $10M to $100M are building depreciating stacks and do not know it.
The diagnostic evaluates whether your technology infrastructure gets better over time without proportional increases in investment, or whether it requires rising effort and budget to hold its current performance. Your stack compounds only if all three properties are present. Missing any one converts compounding into depreciation.
Run this once a quarter. It takes less than an hour.
Apply it in ten minutes: run the Three-Property Test, write down the score, then pull up your next 12 months of technology budget and ask how much of it closes a loop versus maintains a tool that operates independently. The ratio tells you whether you are investing in a compounding asset or funding a depreciating one.
I accept the framework. A compounding stack outperforms a depreciating one over time. Closed loops beat open ones. Shared state beats fragmented state. Historical data that teaches the system beats data that sits in a report. My objection is not to the destination. It is to the journey.
The featured analysis implies the correct response is an architectural intervention: redesign how your tools connect, close the loops, build for compounding. That sounds right. For most companies at this stage, it is the wrong first move. The ones I have watched attempt large-scale stack redesigns share a pattern. Year one: ambitious plan, big budget, executive attention. Year two: 60% complete, the original architect has left, and the business has changed enough that some of the integration designs no longer match operations. Year three: a partially compounding stack that requires constant attention from a senior resource who could be doing something else.
The total cost of the architecture project exceeds the value of the compounding it produced over a three-year window. The investment was not wrong. It was premature.
Compounding through discipline is slower than compounding through architecture. It is less elegant. It requires patience most CEOs do not have. But it has one advantage the top-down redesign does not: it tests your organization's ability to sustain a compounding loop before you commit to building twelve of them. The featured analysis is right that compounding stacks win. I am arguing that building one loop at a time, proving you can sustain it, and expanding from demonstrated success is safer than assuming execution discipline your organization has never demonstrated at scale.
Every claim in this issue has a labeled basis. Composites are identified as composites. Confidence levels are assigned to any figure that involves practitioner analysis or extrapolation from limited data.
If you stopped investing in your technology stack entirely for 12 months, maintaining what exists but adding nothing new, would your marketing performance improve, stay flat, or decline?
If the answer is "improve," your stack compounds: it is still learning from its own data, still closing loops, still surfacing patterns. If the answer is "stay flat" or "decline," your stack depreciates and requires continuous investment just to avoid regression. That answer tells you what kind of asset you have been building, and whether next year's technology budget is an investment or an expense.
Forward this to the person on your team who approves technology purchases. That conversation is the point.