I think too many people underestimate the impact of technical debt. I hear some people say, "That's not why startups fail." I agree, it's not the "sole reason" -- but it is almost always a factor. Whether you realize it or not.
For example: You might say, "Well there was no product/market fit." Ok...But if your technical debt was smaller, you might have been able to find that fit or pivot easier.
It has a profound affect on a company and can also make the difference of having a healthy profit margin. Technical debt quite often leads to increased overhead and if that plus the CTA is not lower than the LTV of customers...You're toast. Your business can't scale without fixing something.
So at that point, yes. You must fix technical debt because it may not be an option to fix something else. However, if you can lower your CTA, you may wish to focus on that before the technical debt because it may be easier and cheaper to address.
Fixing technical debt is expensive. Perhaps one of the most expensive work efforts out there.
Here's an approach I've seen have quite a bit of success: Get your core team (which is going to be the more expensive resources) to define the problems first. Get a good handle on what needs to change, why, and put together a plan. Then utilize the cheaper resources you may already have or outsource new resources to execute on that plan and remove some of the debt.
This allows you to bucket the work and do it in phases. Which helps fit any budget. Especially if contracting out the work...Because otherwise you're paying salaried employees to do it and you can't just stop when you want. Pssst, this helps prevent layoffs.
That's how I'd repay technical debt on a budget to be frank. I'd simply outsource it. I do believe it's a problem that can be outsourced too...But only after properly identifying it and coming up with a game plan. You need absolutely clear instructions when outsourcing.
For example: "Refactor this code to do x, y, and z. Removing a, b, and c which are no longer needed. Then update some test cases and write new ones for the new stuff." It could be as simple as that.
This way, your core team is able to focus on new features and maintaining the current product and UX.
Hiring new resources requires a ramp up period. They need to learn the product, the roadmap, etc. So the best resources to further the product is those who are already intimately familiar with it.
This means the cost of adding a new feature is (usually, but not always) lower than it would be if you had existing resources clean up technical debt and hired new resources to build new features.
Using new resources to build new features is most likely only going to increase your technical debt.
New resources need to learn the product and one of the best ways to do that is by cleaning up that technical debt. This is because it can be done in pieces and it gives someone a good overview of the product and window into the past. It clearly shows developers what was tried and what didn't work and what now needs to happen.
THEN if you want those new resources to work on the future of the product, you could do so without accruing as much technical debt.
Though one thing to keep in mind is that you always accrue technical debt. There is no such thing as a technical debt free product. I think the most important thing of all is to understand when you need to repay it. Even if you aren't efficient in repaying it.
![[C]oFoundersLab](/img/logo/blue_cropped.png){kind=logo}