Latest / SaaS Business with Fexingo: Software-as-a-Service Companies, ARR, and Recurring Revenue / SaaS Hidden Costs of Technical Debt
Transcript
- Lucas: So here is a number that keeps me up at night for SaaS companies right now, especially looking at the Q3 data we have for September seventeenth twenty twenty six. It is not churn, it is not customer acquisition cost, and it is not even the price of cloud services themselves. It is the invisible tax of bad code. Luna: You mean technical debt? I thought we talked about that years ago. Lucas: We did, but the scale has changed because every SaaS firm is now essentially a software company with a sales department. And when you look at the gross margins of the top fifty public SaaS names on the NASDAQ, they are not just flat. They are slowly compressing by one to two percentage points year over year despite rising prices. That compression is almost always technical debt. Luna: But isn't that just part of growth? You build fast, you fix it later? Lucas: That was true in twenty eighteen. In twenty twenty six, the math does not work that way anymore. Let me give you a concrete example from a mid-market company we worked with last month. They had a thirty million dollar annual recurring revenue base, which sounds healthy, but their server costs were creeping up by fifteen percent each quarter while their user count only grew by five percent. Luna: So they were paying more to serve fewer or similar customers? That sounds like an efficiency leak. Lucas: Exactly. An efficiency leak that bled three million dollars in potential profit over eighteen months. The issue was not that they lacked engineers. It was that they had accumulated so much spaghetti code in their core billing engine that every new feature required twice as many server cycles to process. So for every dollar they brought in, they were spending twelve cents on infrastructure instead of the industry standard eight cents. Luna: And they didn't see it until the bill arrived? Or was there a warning sign earlier? Lucas: There were warning signs, but leadership ignored them because the product team was hitting all their release dates. They were shipping features that drove new subscriptions, which made the C-suite happy. But those features were built on top of a crumbling foundation. Every time they added a new analytics module, the latency went up, and to fix the latency, they just threw more servers at the problem. Luna: So they masked the symptom with capital expenditure instead of fixing the root cause. Lucas: Precisely. And that is the trap. Because capital expenditure feels like growth investment. If you buy more servers, you look like you are scaling. But really you are just paying interest on past mistakes. And in today's market, where investors are demanding path to profitability, that kind of waste is fatal. You cannot justify bloated infrastructure costs when your peers are running leaner models. Luna: It reminds me of that old joke about buying a bigger house because you have too much stuff, instead of throwing the stuff away. Lucas: That is exactly it. You are expanding your capacity to accommodate inefficiency rather than improving the efficiency itself. And the worst part is that technical debt compounds. Just like financial debt, it gets more expensive to service over time. The longer you wait to refactor, the more fragile the system becomes, and the riskier it is to touch it. Luna: So how do you convince a product-led CEO to stop shipping and start refactoring? Lucas: You have to speak their language, which is not code. It is margin. You show them that for every hour spent fixing legacy code, they save ten thousand dollars in cloud spend annually. But most CEOs do not think in terms of cloud spend. They think in terms of features shipped and deals closed. So you have to translate the engineering problem into a P&L problem. Luna: That is a huge cultural gap. Engineering speaks in hours and bugs. Finance speaks in dollars and margins. Lucas: Right. And the bridge between them is usually missing. That is why the best SaaS companies now have a chief revenue officer or a head of platform who sits at that intersection. Someone who understands that a slow API response time is not just a tech issue, it is a revenue leakage issue. If your checkout page loads one second slower, you lose two percent of your conversion rate. That is direct revenue loss caused by technical debt. Luna: So latency is literally costing them sales, not just server bills? Lucas: Absolutely. Amazon calculated years ago that every hundred milliseconds of latency cost them one percent in sales. Today, with mobile usage dominating, that tolerance is even lower. Users expect instant responses. If your database queries are inefficient because no one cleaned up the schema three years ago, your app will feel sluggish. And in a crowded market, sluggish means churn. Luna: I bet. I tried using a new productivity app last week and it kept freezing. I deleted it before I even signed up for a paid plan. Lucas: That is a perfect example. You did not care about their backend architecture. You cared about the experience. And that experience is directly tied to how well they manage their technical debt. So when you look at SaaS valuations, you should be looking at infrastructure efficiency as a proxy for management quality. A company that can grow revenue without growing server costs proportionally is run by people who understand leverage. Luna: Is there a metric investors should watch for this? Something visible in the filings? Lucas: Yes. Look at the ratio of cost of revenue to total revenue, specifically the breakdown within cost of revenue. If you see hosting and data transmission costs rising faster than subscription revenue, that is a red flag. It suggests that their unit economics are deteriorating. Ideally, that ratio should stay flat or improve as they scale. If it is ticking up, something is wrong under the hood. Luna: So if hosting costs go up twenty percent and revenue only goes up ten percent, the spread is getting crushed. Lucas: Exactly. And that crush happens silently. It does not show up as a dramatic event. It shows up as a slow bleed in gross margin. And by the time it shows up in the earnings report, it is often too late to fix without massive disruption. That is why proactive debt management is critical. Luna: But isn't refactoring risky? What if you break something that works? Lucas: It is risky, which is why good teams use a gradual approach. They do not rewrite the whole system overnight. They identify the most expensive parts of the codebase and tackle those first. Usually, it is the billing module, the search function, or the notification system. These are high-traffic areas where small improvements yield big savings. Luna: So it is like decluttering your house room by room instead of trying to clean everything at once. Lucas: Spot on. You start with the room that is causing the most stress. In SaaS terms, that is the component that consumes the most compute power or causes the most support tickets. Fix that first, measure the improvement, and then move to the next one. Luna: Do you think AI can help reduce this debt automatically? Lucas: AI is helping, but it is not a magic wand. Tools like GitHub Copilot can help write cleaner code faster, but they cannot decide what needs to be rewritten. You still need human judgment to understand the business logic and the long-term implications. AI is a tool for efficiency, not a replacement for architectural thinking. Luna: So it amplifies good practices but doesn't fix bad strategy. Lucas: Correct. If you feed messy code into an AI model, it might generate messier code. You need a strong foundation first. That is why culture matters more than tools. Companies that prioritize code quality as a core value tend to have less technical debt than those that prioritize speed above all else. Luna: Speed is still important though. You don't want to be slow forever. Lucas: No, but sustainable speed is different from reckless speed. Reckless speed burns bridges. Sustainable speed builds roads. And building roads requires maintenance. If you ignore maintenance, the road collapses, and you have to start over. Which is far more expensive than just paving it properly in the first place. Luna: I like that framing. Sustainable speed versus reckless speed. Lucas: Thanks. It comes down to patience. It takes patience to resist the urge to ship immediately. It takes discipline to allocate twenty percent of your sprint to debt reduction. But that discipline pays off in higher margins and happier customers. Luna: Speaking of paying for things, if you find our deep dives into these operational realities helpful for your own work... Lucas: and you want to support the show so we can keep bringing you these ad-free conversations, you can grab us a coffee at buy me a coffee dot com slash fexingo. Luna: It helps cover the costs of research and keeps the signal clear. Thank you. Lucas: Back to the topic. One final thought on measuring success. When you refactor, do not just look at cost savings. Look at developer velocity. Does it take longer to deploy? Do tests pass more consistently? Those are leading indicators that your health is improving, even if the server bill hasn't dropped yet. Luna: Velocity is the ultimate proof that the code is actually better, not just cheaper. Lucas: Exactly. Because if you cut costs but make it harder for your engineers to work, you have lost more than you gained. The goal is to create a flywheel where better code leads to faster development, which leads to better products, which leads to more revenue, which funds further improvements. Luna: A flywheel driven by clean code. That is a nice vision. Lucas: It is achievable, but it requires treating code as an asset, not a liability. Most companies treat it like a expense to be minimized. The winners treat it like equity to be grown. And that shift in mindset is what separates the SaaS firms that thrive in twenty twenty six from the ones that fade away. Luna: So the question for listeners is: are you investing in your code or just surviving it? Lucas: Good question. And I would love to hear your answer in the comments. Thanks for listening.