A mentor taught Shopify's CEO that you have about two years to get an important piece of software's architecture right. After that, it's as if "cement gets poured in the codebase," making fundamental changes nearly impossible.
Related Insights
In fast-moving industries like AI, achieving product-market fit is not a final destination. It's a temporary state that only applies to the current 'chapter' of the market. Founders must accept that their platform will need to evolve significantly and be rebuilt for the next chapter to maintain relevance and leadership.
Zach Lloyd advises against rewriting code for early-stage startups, calling it a 'horrible idea' that pauses critical momentum. This intensive effort is only justified for products at massive scale, like Google Sheets, where perfecting the experience for over 100 million users warrants the multi-year engineering investment.
Wiz's product team, trained at Microsoft, avoids building features that only solve for today's customer but break with tomorrow's enterprise giant. This 'infinite scale' mindset isn't about slowing down; it's about making conscious architectural choices that prevent time-consuming and costly refactoring later on.
When a team presents a timeline that feels instinctively too long, trust that gut feeling. It likely signals an over-engineered solution. Complex systems never become simple; they only breed more complexity, causing timelines to expand endlessly. It's better to reset the team or the approach early on.
While no-code can help validate an idea, it inevitably leads to a growth-killing stall. Founders will hit a platform limitation that forces them to stand still for 3-6 months to rewrite the entire codebase from scratch. This sacrifices critical early-stage feature velocity and market responsiveness.
Citing Salesforce veteran George Hu, Halligan notes that in hypergrowth, nothing scales for long. Any new system, process, or even role has a three-year lifespan before it breaks and needs to be replaced. This mindset normalizes constant change and helps leaders anticipate inevitable breaking points.
Building a true platform requires designing components to be general-purpose, not use-case specific. For instance, creating one Kanban board for sales, support, and engineering. This thoughtful approach imposes a ~20% development 'tax' upfront but creates massive speed and leverage in the future.
Every change introduces a temporary performance decrease as the team adapts—an 'implementation dip.' This guaranteed loss often outweighs the uncertain potential gain from minor tweaks. Real growth comes from compounding skill through repetition of a working system, not from perpetual optimization.
Veteran tech executives argue that evolving a business model is much harder than changing technology. A business model creates a deep "rut" that aligns customers, sales incentives, and legal contracts, making strategic shifts (like moving from licensing to SaaS) incredibly painful and complex to execute.
The era of winning with merely functional software is over. As technology, especially AI, makes baseline functionality easier to build, the key differentiator becomes design excellence and superior craft. Mediocre, 'good enough' products will lose to those that are exceptionally well-designed.
