In software development, technical debt is the cost of additional future rework caused by choosing an easier or expedited solution to get code out the door more quickly. Engineering teams incur technical debt at strategic times instead of using an optimal approach to a coding project that would take longer to implement. You accumulate technical debt when your team prioritizes speedy delivery over perfect code. Like financial debt, tech debt accumulates a metaphorical “interest” that you’ll need to repay later. This interest can make it harder to implement future changes, but some technical debt is inevitable for every development team. At my startup, Jellyfish, technical debt is something that comes up frequently as we help engineering teams deliver measurable business results. I’ve seen technical debt trends in my own company, as well as in the customers we work with, so I’ve got inside advice on how to think about it and how to handle it in your organization. In this article, you’ll learn about technical debt, its necessity, and how to plan for it.Why you shouldn’t worry too much about technical debt in your early stageWhen you’re in the earliest stages of your startup, product/market fit is the only thing that matters. At this point, you don’t need to think about technical debt because you don’t know what your company will be doing a year from now. Your product might undergo a complete makeover as you align with what your customers need. You can only measure debt relative to what the business will do in the future, so until things settle out and your product is stable, the issue of technical debt is moot. Tech debt can’t be measured because you don’t know what part of the code will still matter in a few months. In the early stage, you should put aside worries about technical debt. Just focus on finding that product/market fit.How to know when you’re ready for technical debtIt’s important to accept that tech debt is just part of the development process—something every team will eventually need to incur. But true technical debt is intentional, not accidental, so it’s something to consider carefully as you’re scaling. There’s no one-size-fits-all answer, but you’ll know when it’s time to evaluate (and start paying down) technical debt when your software starts breaking. People use your software more often, and you can see issues popping up. That’s a sign that there are some trade-offs you’ve made in the past that need to be revisited, and there are some problems in the plumbing that will need to be resolved. This is the right moment to bring in a new resource (e.g., an external head of engineering or a new engineering leader[JM1] ) to help you analyze the issues and put processes in place for dealing with technical debt.Planning for tech debtTechnical debt is neither good nor bad. It’s simply…debt. How much debt you repay and when is relative to your business, and you’ll need to collaborate with your engineering, product, and business teams to determine your budget and decide on a strategy. As always, you have a finite pool of resources to work with. It’s a balancing act: If you focus only on tech and don’t create new features, you won’t have a business for long because you won’t sell anything new. On the other hand, if you focus only on new features and don’t pay down your technical debt, things will continue to break. The key is finding a middle ground for adding features that won’t bust your budget or burn out your development team. That means communicating with your product and business teams early and often and bracketing off technical debt clearly, so no one is surprised by it. You can set expectations about the shortcuts you’re making and how the decisions are getting made, and let stakeholders know you’re going to pay back that technical debt at a later time.Strategic technical debt doesn’t have to be scaryYou’ll inevitably need to “borrow” to get what you need as an engineering team. That means sometimes making sub-optimal coding or design decisions in the short term, knowing your code will need to be updated.