It's tempting to think that the code you or your team writes is the biggest asset the company has. After all - you're a software company, right? You make software. A auto manufacturer would probably think of the cars that roll off the factory line as assets, right? Your code is the same thing!
Wrong.
Your code is a liability, not an asset.
This is tough for a lot of folks to wrap their heads around initially. Every time I mention this to people outside the SaaS industry, or to newcomers, I'm greeted by confused looks.
"Liability - huh? Isn't writing code the whole point?"
Well, if you're reading this blog, that's probably the wrong way to think about your business. The fundamental problemYou're not a software company. Your company does not exist to write software - it exists to provide a service (the "Service" in Software-as-a-Service). The "Software" part is an implementation detail.
In a SaaS business, software is the Wizard of Oz. Pay no attention to what's behind the curtain. The value you provide is the service the software enables.
Code is a liability because every line you write has an ongoing maintenance cost, indefinitely. As nearly any developer will attest, code is never "finished". It never "just keeps on running".
This can be surprising for those without a programming background. It's just code, right? If it runs once, why doesn't it just keep running?
One big reason it doesn't just keep running is infrastructure. To run a SaaS, you have to host your application somewhere. Some servers need to run your code, and those servers need to stay running.
Sometimes it's inherent hardware limitations. Databases run out of space eventually, and need to be upgraded. Especially if you continue to grow, you'll slowly need more of everything: bandwidth, servers, storage, support.
It's extraordinarily difficult (impossible?) to write completely bug free code. Some of this is attributable to simple human error. Programmers make mistakes - it's inevitable.
But often times the "bugs" that require ongoing maintenance are the ones that developers are fully aware of from day one.
You'll see this often when a startup hits the scaling-up phase. Building a system that handles hundreds of customers is very different than building one to handle hundreds of thousands. You can cut a lot of corners with hundreds of customers. These cut corners save you time in the short run - less complexity means faster to implement.
But in the long run, those cut corners have to be revisited. Your single tiny database server that worked fine with 50 customers will fall over with 150,000 customers.
This might sound like a bit of trite wordplay at first - okay, congrats, code is a "liability" because it has ongoing maintenance costs. Big whoop.
But this distinction actually matters. If you think of code as a liability, it changes nearly everything about how you approach your SaaS business.
Suddenly, the oft-repeated advice about iterating quickly, learning fast, not over investing too early in a product before you understand the pain point - all that advice becomes much more poignant.
Lean startup principles aren't just about moving faster. They are also focused on avoiding downside risk, i.e. ending up with a big codebase on your hands that isn't solving a real pain.
If code is an asset, that big codebase for a product that doesn't quite fit the market need is just a smaller win - you didn't quite hit the mark, but hey, at least we build something, right?
But if code is a liability, then that big codebase is worse than no codebase at all.