The Reinvestment Most Companies Skip: What to Put Back Into Your Own Technology, by Revenue | Active Logic Insights
My last article was about downside. What you can afford to lose if a vendor relationship goes sideways, and how that answer tells you who you can realistically hire. This one is about upside. Most companies reinvest aggressively in marketing, treat hiring as an ongoing capital priority, fund acquisitions when the math works, and still treat custom software as either a SaaS subscription line or a one-time project they greenlit when something was broken. That gap is the point of this piece. The math on building your own software has moved in a real way over the last three years, and most leadership teams have not recalculated.
Before I go any further: this is not a pitch for hiring my firm. I run a custom software company, and you are welcome to call us, but the argument below holds regardless of who does the work. Build in-house. Hire an outside firm. Blend the two. The point is not who writes the code. The point is that most companies structurally under-reinvest in the technology that actually runs their own operations, and they pay for that decision in slower growth, weaker valuations, and competitive positioning that can be copied by any competitor with a credit card and an implementation partner.
What Reinvestment Actually Means
Every company I have worked with treats reinvestment as a normal part of growth. They reinvest in marketing to expand reach, in hiring to add capacity, in facilities, training, equipment, and acquisitions. Nobody argues with any of that on principle.
Reinvesting in the company’s own software is treated differently. For most leadership teams, software is either a SaaS line item they already pay for every month or a project they greenlit when something broke. It is rarely treated as an ongoing category of capital allocation the way marketing and hiring are. That is the gap. Not “you should hire a vendor.” Not “you should spend more on IT.” The gap is that custom software, the kind your company actually owns, is a reinvestment category that most leadership teams do not have a line for on their planning sheet.
Not All IT Spend Is Custom Software
Before the numbers, one clarification worth making. IT budget and custom software investment are not the same thing, and lumping them together is how this category quietly gets zeroed out in planning meetings. IT budget covers laptops, licenses, security tools, cloud infrastructure, SaaS subscriptions, help desk, and a hundred other operational items. Most of that is necessary operating cost. Custom software investment is a specific slice of the IT budget, sometimes a small one, that funds building technology your company actually owns.
A company can have a perfectly healthy IT budget and reinvest almost zero dollars into custom software. That is not a hypothetical. I have seen companies spending $3M to $5M a year on IT with almost none of it going toward technology they own. They are paying for operations. They are not compounding an asset. The table later in this article is specifically about that second bucket.
The New Math of Custom Software
Custom software used to be the expensive choice. For decades the economics were simple: building your own system cost significantly more than buying a SaaS equivalent, and unless you had a truly unique requirement, renting won the math. That was not wrong. It was the reality of software development for most of my career.
AI has changed it, and not in a marketing-slide way. I have watched our own engineering team ship work over the last eighteen months that would have taken two or three times as long three years ago. Tools like Claude Code, Copilot, and Cursor have collapsed the cost of building and, just as importantly, the cost of maintaining software over time. Refactoring a legacy codebase, writing tests, migrating frameworks, generating documentation, triaging production issues. Work that used to require weeks of senior engineer time now takes days. I have written about the specifics of that shift in AI Doesn’t Replace Engineering and in 10,000 Tasks in One Request at Half the Cost. The short version is that AI is not replacing engineers. It is making good engineers radically more productive, and the cost curve for custom software has dropped accordingly.
The implication for buyers is direct. If you evaluated custom software five or ten years ago and concluded it was too expensive, that decision deserves a fresh look. The premium that used to make custom software a hard sell has narrowed, and the competitive advantage of owning your own technology stack has not.
Why Renting Software Alone Is a Dead End
Here is a question I ask every executive team we talk to. What about your technology stack is defensible? If the honest answer is “we use Salesforce, HubSpot, Shopify, and a handful of SaaS tools,” then the honest follow-up is that nothing about it is defensible. Every competitor can buy the same stack, configure it the same way, and hire the same implementation partners. That is not a criticism of the tools. It is a statement about what they are. They are commodity infrastructure, which is exactly why they are so valuable as a floor.
The floor is not the problem. The ceiling is. The companies I see pulling ahead of their competitors are layering custom software on top of that commodity floor. They use Salesforce for CRM and build a custom middleware layer that ties Salesforce to their pricing engine, their operations system, and their client portal. They use Shopify for e-commerce and build a custom fulfillment orchestration system their competitors cannot replicate by buying another SaaS product. The commodity tools do their job. The custom software does the part that makes the company hard to compete with.
If technology is not your moat, none of this matters. Plenty of companies compete on brand, distribution, service, or pricing, and they will do fine running on a commodity stack. If technology is your moat, or if it is quietly becoming your moat whether you planned for it or not, renting alone is a dead end.
Custom Software Is a Balance Sheet Item
This is the part most leaders miss, or at least do not discuss in build-versus-buy meetings. Custom software that you own is an asset, literally. Under GAAP (ASC 350-40), internally developed software that meets the capitalization criteria shows up on the balance sheet as an intangible asset. It gets factored into company valuation. It is part of the enterprise value a buyer pays for in an acquisition.
SaaS subscriptions are the opposite. They are a recurring operating expense that lands on the P&L every month forever, and they do not appreciate. A custom platform you built, own, and maintain is equity. It compounds as you use it. It gets inherited cleanly in a transaction. It shows up as a durable asset when a diligence team goes through your technology stack.
I have seen companies sell for significantly higher multiples because of the technology IP they built over the preceding five to seven years. I have also seen companies fail to get acquired at all because their operations depended on rented tools a buyer could not inherit as durable infrastructure. The asset side of this equation is real, and it almost never comes up in the original build-versus-buy conversation, because that conversation is framed as “what does it cost to do the job,” not “what does it cost to own the outcome.”
What to Reinvest, by Revenue
This table is a planning starting point. It is narrower than the IT spend table in the previous article, because it focuses specifically on the custom software slice of the overall budget, which is usually the slice that gets zeroed out first when budget season tightens up. Industry, growth stage, and how technology-dependent the business is will all move the numbers. Use it to orient. Then anchor to your own sector.
| Annual Revenue | Recommended Custom Software Reinvestment (% of Revenue) | Annual Custom Build Budget | What This Looks Like in Practice |
|---|---|---|---|
| Under $1M (startup, early stage) | 10 to 25% (MVP-focused, product is the company) | $10K to $250K | Your product IS the software. Nearly every dollar of IT spend is custom. |
| $1M to $10M (small business) | 3 to 8% | $30K to $800K | Start layering custom on top of SaaS. Build the integrations a competitor cannot copy. |
| $10M to $100M (mid-market) | 2 to 5% | $200K to $5M | One or two strategic custom systems. Start treating software as a durable asset category, not a project line item. |
| $100M to $1B (enterprise) | 1.5 to 4% | $1.5M to $40M | Multiple custom platforms, a named technology leader, and a real capital plan for software the same way you have one for facilities. |
| $1B+ (large enterprise) | 1 to 3% of revenue, large absolute dollars | $10M to $300M+ | Custom platforms are central to the operating model. Technology is a competitive category, not a cost center. |
Two things about that table matter more than the specific ranges. The percentages decline as you scale, which is normal and is why enterprise technology budgets look eye-watering from the outside. They are proportional, just with a larger base. The more important question is not “should I reinvest.” It is “which one or two custom systems, if we built them well, would be unreplicable by our competition and would move our valuation the most.” That is where the reinvestment goes first. Build one platform that matters, not five mediocre ones.
How to Sequence the Reinvestment
For companies that have never made a real custom software reinvestment, the path looks the same whether you build in-house, hire a vendor, or blend the two.
Start with a strategic audit. Map every system your business runs on, and label each one as commodity (SaaS, replaceable, no competitive differentiation) or potentially differentiating (automates something your team does uniquely, touches your customer in a way competitors do not, or connects systems in a way that is specific to your operating model). Most companies are surprised at how few items land in the second category, and that is a useful surprise. It focuses the reinvestment.
Pick one differentiating candidate. Commit to building it properly, with a real timeline and a clear owner. Do not try to build three things simultaneously. Companies that split their first real custom software investment across a platform, a mobile app, and an internal tool usually end up with three half-finished projects. Companies that ship one strong platform first usually end up with the money and confidence to build the second one.
Then protect the work. Own the code. Own the documentation. Have a plan to maintain it after the initial build, not just to ship it. If you read my risk article, you already know why the vendor relationship matters if you choose to hire one. Owning the IP only works if the partner who builds it operates under contracts with enough teeth that ownership actually transfers cleanly.
The Combined View
Put both articles together and you have a simple framework for technology spend. The first article answered a defensive question: what can I afford to lose, and what kind of vendor can I realistically hire given that answer. This one answers the offensive version: what should I be reinvesting in so my company compounds value over time instead of renting it. Both questions are about reinvesting in your own company. One protects the investment. The other grows it.
The Move
If you take one action from reading these two pieces, it is this. Spend one hour with your leadership team answering two questions. First, what are we spending on software right now, and what percentage of that is going into something we actually own versus something we rent? Second, if we had to name one custom system that would materially move our business over the next three years, what would it be?
If you cannot answer both of those clearly, you are making technology decisions by default rather than by design. Default decisions in a fast-moving technology market tend to compound in the wrong direction. I would rather see a company over-reinvest in something it owns than under-reinvest and rent everything. The math has changed. Most leadership teams have not caught up yet.
