What happens when your business gets ahead of your tech? We explain.
The word ‘debt’ is almost universally negative. It conjures up thoughts of maxed-out credit cards and overdue business loans, stretched financials and a struggling business. Of course, that’s not always the case – many companies are smart about borrowing, using funds to boost growth and repaying their debts with eventual profits.
Technical debt is a way to explain the lag between developing a product and optimising it – it’s the rework and back-dating that needs to happen when your business grows quickly. In many ways, it’s similar to financial debt. The name sounds negative, but it’s often a necessary tool to help businesses in rapid growth phases. And, much like financial debt, technical debt can be bad if it doesn’t result in increased market share or profitability.
Here’s how to define technical debt – and why it’s a vital tool for startups and SaaS companies.
Defining technical debt
You incur technical debt when your business needs to reach a certain point fast. Instead of working through every angle, ticking every box and providing an optimised final product, you take shortcuts, cut requirements down to the basics and just get the product out there in some form. The debt is the time and cost of going back to fix problems, rewrite code and develop more features to flesh out the final product.
Every software developer has skipped writing a unit test, implemented some quick-and-dirty code in a time crunch, or written workarounds instead of spending time getting to the root of a problem in the system. It’s sort of like beeping the credit card to cover small business expenses – it’s easy and quick, and you don’t need to worry about the consequences until later.
Why technical debt is a must-have
When a business is starting or developing a new product, time is of the essence. The more time you spend developing, refining and optimising, the more you’re spending on a completely unproven product. That’s why it’s crucial to get a product in front of your customers ASAP – even if it’s not the perfect end result you have in mind.
For example, a business developing a time-tracking software solution might release an early-stage product with minimal features – basic time-tracking for individual employees – sign up customers and then push out new features in development phases. Phase two could involve introducing project management features, phase three might be reporting functionality and so on. Developers also have the chance to fix bugs and resolve issues as they arise – early customers are the ideal testers for a new product.
It’s about making trade-offs. In most cases, taking on technical debt can help reduce the financial debt incurred by a long and potentially fruitless development phase. Speeding up the development process means you can get an MVP to market and test product market fit sooner. If the product isn’t viable or doesn’t have the expected market impact, you’ve spent less time, money and energy on development, and you’re in a better position to move on to the next solution. If the product is viable, you can start onboarding users and pitching to investors, then work on repaying your technical debt.
The problem with premature optimisation
In some cases, product perfection and a complete lack of technical debt can be seen as red flags. It may be a sign that your business is scaling and developing slower than it could be. Investors want to see their investments come to fruition as quickly as possible – they don’t want their money tied up in a never-ending development stage.
Fully realised, optimised products are the dream – but they also require a lot of energy and time to develop. Premature optimisation happens when a business builds and implements a functional, robust and feature-heavy system without market validation. The product may be scalable for user load and functionality, technically perfect and beautiful, and completely technical-debt-free – but it’s all an expensive waste of effort without a market.
Instead, smart SaaS startups use technical debt as they do financial funding. It’s an investment in the future of the business that helps get them to market sooner, increasing future value and allowing them to optimise later. While it may be frustrating for some developers to push out a less than perfect product, it’s a necessary part of the development process, particularly in the SaaS environment.
Identifying tech debt
To get perspective of your technical debt, put yourself in the shoes of a VC looking to invest in your business. If they were to look at your system architecture and rummage around in your code, what would they think? Is your technical debt mounting up, or are you remediating it all the time? Have you been putting off major technical debt for a long time? Do you have a plan to reduce ‘bad’ technical debt and fix old issues?
You make technical decisions with the knowledge you have at any given point. As much as you’d like to, you can’t see into the future and often, shortcomings or missing features only emerge as your business grows and needs change. You might make some decisions knowing you’ll have to go back and rework, while others can seem like the best choice until new information comes to light.
For example, a business could choose to build its software on a database that works for the initial system load, and then find that it can’t keep up with growth. While this may seem like a major error in judgement, the decision was made with the information available. Why invest in a high-performance, costly platform for a product that hasn’t been tested in the market? With a proven market and growing customer base, the business can shift to a new platform, repaying its technical debt with its newfound success.
Getting your head around tech debt
One difference between technical and financial debt? Visibility. In most businesses, financial debt is crystal clear, with a clear timeline for repayment and obvious consequences if the debt is not repaid in that time. Technical debt can be murkier – there’s not always a way to see messy code or missing features, and it can be difficult to plan your technical ‘repayment schedule’. It’s easy for technical debt to pile up, too, with bad code on top of bad code, workarounds taking up more and more time and no plan for a full reboot of a faulty system.
However, these aren’t reasons to avoid technical debt – they’re reasons to be savvy about the process. It’s crucial to understand the level of debt you’re taking on and how long it will take to pay back. If you take on technical debt thoughtfully, the returns should be greater than the work needed to repay it. It’s important to make sure you are managing your technical debt effectively. In our next blog we will look at good debt, bad debt and strategies to make debt work for you.
Getting your head around your own tech debt? Talk to the Parallo team and we can lend a hand.