Should a startup worry about technical debt before reaching product-market fit?
Should a startup spend resources refactoring code before p/m fit is achieved? Or should it spend its resources turning out features to win prospective customers? Everyone will say no to this question. And it's the right answer. But then you run into team problems with engineers feeling very exhausted working with your codebase and you have to constantly deal w/ missing confidence in the developed software. In my experience "Acknowledged technical debt" is usually a good middle ground to work with. It usually also works with die-hard engineers. Building software is not about writing optimal code. The goal is to have confidence in the code you wrote. Constantly wondering how something works only to realize that it doesn't is energy draining and needs to be avoided. Acknowledge and document technical debt. Explain (in notes) how stuff is meant to be, how it should be, what does work. Essentially you want to reduce the amounts of "WTFs" the next person (eg future you) has reading the code. The most important lesson here is: technical debt can be a good thing. You buy expensive short-term impact with future time. Very often you never need to "cheque" that future time because that part of the product might have been thrown away. I like this answer. Acknowledged debt is the most you should aim for. The last thing you want to do is have a wall of trust where you throw requirements over the wall and then don't care how the code gets written. The code is everyone's responsibility. Everyone should be willing participants in the process (which includes acknowledging the debt it took to meet deadlines). No, because your priority is building something people like quickly. Not building something well that people don't necessarily care about. That said, tracking tech debt is important. Creating issues in Jira, or whatever you're using, can be valuable over time. Maybe there's one specific piece that gets in your way of building features every week, and tracking it will make it more obvious or help you realize, e.g. "we could make this 10x better with a few hours of effort vs. 12x better with a few days". Remember that product-market fit stage is when you'll have the highest percentage of your time to dedicate to building features -- might as well make the most of it. Good coding practices can help here, too: decent comments, (reasonable) tests, PR discussion, etc., can be self-documenting. No. Your highest priority is to reach the product market fit and get real customers. You can always refactor. I agree with this. Many coders spend too long worry about things customers will never see or even use. Don't spend months making perfect backend code for a feature that you end up removing because customers don't use it. See what people want then iterate from there. Don't write so much code. Once you figure out what you're going to build, you can just throw everything away and make it again more properly. I would offer that there is a definite correct answer to this in most, if not all, cases. It can go either way depending on what is going in your company and market. I would consider a few things before making your choice: * Likelyhood of Pivot while Repurposing Codebase Obviously, people don't just go into a startup thinking that they are going to pivot and they aren't easy to predict because it means something unexpected is working well. Your architecture should allow for services and components to be broken out, e.g you will suffer massive technical debt if you want to pivot a service that is dependent on a schema based mysql database with a very rigid data model. All of this is set up on docker instances with crazy services and held together with a staple gun. If you want to carve out a small service that is working, it will be impossible as it is inextricably tied to your bloated deathmachine. Death will quickly catch up before your revenue does if you have to port and rewrite your entire application and redeploy it. Make sure you can be sort of agile, in the sense that you at least have a componetized modular structure for services large enough to charge for. * No One Likes Your Product If your product is not great and no one wants it, having an immaculate and eloquent codebase will kill you as well. Something that does a great job performing a task no one will pay for is also negative. my 0.02, tolerate technical debt at the micro level, but never at the macro level. E.g you can do refactoring if you need to, your code is not extremely dry, there are plenty of optimizations available but your code/functions work. DO NOT TOLERATE IT AT THE MACRO LEVEL
You used the wrong tool, are trapped on the wrong database structure, your application is extremely unstable because of a major design choice, etc. Lot's of small errors are better than a few big ones. The answer can depend on some of the architectural choices you made when you prototyped your product. If the original use-case has changed significantly, and you find yourself fighting the codebase to get it to do what you want today, the technical debt is something to worry about. The same thing applies if you cannot scale to serve clients requiring a lot more volume than what you anticipated originally. It's possible that some clients have modified the original use-case they wanted when they signed-up with you, so your product must evolve to keep serving them. This may require refactoring, whether p/m fit was achieved or not. The startup world may be influenced a lot by Mark Zuckerberg's motto of "Move fast; break things." However, I don't think it's a good goal to aim for. Like @andreasklinger and @hashkb said, you should have agreement with your engineers about your limit. Refactoring can never be enough, because we always try to improve, try to be better. You can think about the "later days" when you can come back on your codes and fix those crap codes, but you know you won't. The bigger the debt for now, the costlier it will be in the future. Trust me, my startup is managing on that. It depends, technical debt lets the team build features quickly today at the cost of slowing down future development. Startups with a short runway probably don't have a future, so technical debt can be viewed as something with little downside that gets you to market faster. The tradeoff is that as your runway gets shorter debt makes it harder to try new things. I'd say don't worry too much about technical debt before p/m fit. However, don't let anyone on your team use debt as an excuse for half-assing something that could deter finding market fit. No, but it depends. One thing to remember about technical debt is the concept of interest. Each time you have to go into a part of the code with high technical debt, you pay interest. There is also something to be said for building a v1 MVP to prove product/market fit, and then build an entirely separate v2 that is refined to what you have learned. Like pretty much every question asked on hn the answer is "it depends". At what point do you consider p/m fit achieved? How many developers are working on the software? What makes you think features are important? How mature is your market? What's your value proposition? Etc etc etc. If you are entering an established market then code-quality can be your biggest competitive advantage. Give yourself a technical debt ceiling, and don't raise it each time you hit it. Your engineers will stop trusting you, burn out, and/or quit. Make sure you do more than just acknowledge the debt you are taking on, or else you don't have technical debt, you just have bad code. IMHO: "A little, but not too much. The more product-market fit you achieve, the more you should worry about technical debt." Don't fall for the "Next Feature Folly"