My co-founder and I use the phrase “champagne problem” to call each other out when we’re spending too much time over-engineering a solution. We are both perfectionists. We don’t like messy designs, hacky workarounds, or systems that aren’t prepared for scale: things many would consider “tech debt.” As we’ve been working on our own company for the past year, we’ve had to fight our natural instincts and embrace these non-optimal approaches.
Champagne Problems
“Champagne problems” in this context refer to challenges that will only be an issue when you’re large enough to be celebrating success – popping champagne bottles. These problems will arise when you have so many customers using your product in such massive ways that your initial implementation can’t handle it. Essentially, if you’re experiencing “champagne problems,” you’ve completed the task of making something people want.
Tech Debt
Tech debt is the extra work that arises when you choose the quick way to solve a problem instead of the best long-term solution. Accepting tech debt is typically perceived as wasteful, lazy, and shortsighted – some might even say you’re “cutting corners.” The debt could accumulate "interest" over time, leading to increased costs, reduced productivity, and frustration for future projects. People fear that it could result in a lower-quality product, create scalability issues, and add complexity that hampers the rest of the team.
Not All Tech Debt is Created Equal
Shipping fast doesn’t mean you should ignore tech debt entirely. Instead, it’s about finding a balance between releasing quickly and building a stable product. The question I like to pose is, “How difficult would this be to fix or upgrade in the future?” If we can easily make changes to improve this process or feature in the future, then the debt is fairly minimal. If making updates to the system will result in major breaking changes to existing customers, then we should probably consider making the upfront investment.
For example, when we were selecting a primary data store for data imports, we spent many hours comparing and evaluating options. This was a core architecture decision that has many ramifications and would require a major overhaul to change. On the flip side, when selecting an approach for “unique value” detection, we chose to start with the simplest option possible. We can always go back and improve this logic when we have usage that warrants optimization.
Learning and Iterating from User Feedback
The true value in shipping an initial product or feature lies in the opportunity to learn from users. It's easy to assume we know how our users will interact with our product and what they will value most. However, these assumptions often fall short of reality. By putting our product in the hands of users, we can gather insights that inform our future iterations.
If we were to attempt to avoid tech debt, not only would we significantly slow our build effort, but more importantly, we would delay the time to begin receiving user feedback. In most cases, startups are going to build the wrong thing the first time. Instead of building the wrong thing in a clean, scalable way, it’s usually best to build in the quickest way possible. In most cases, you’ll have to rebuild it anyway.
The Upside of Tech Debt
Tech debt allows us to test our ideas, gather user feedback, and validate our assumptions before investing significant time and resources into building the perfect solution. It’s a necessary step in the iterative process of product development, helping to avoid over-engineering and ensuring that we're building something that actually delivers value.
There’s also something freeing about building something in a “hacky” way. If we spend a few hours getting the first version of a new feature released, I’m going to be much less concerned when we need to completely overhaul it based on user feedback. My goal is to get something released as quickly as possible with the intent and expectation that we will rebuild it in a better way once we understand how it’s being perceived and used by customers.
---
Tech debt is an inevitable part of product building and shouldn’t be feared or avoided. By embracing imperfection and learning from user feedback, we can build a stronger, more resilient product that truly meets the needs of our users.
