Embracing the 3-Month Rule: A Practical Guide to Building with Intent
In the startup world, there’s a well-known mantra from Paul Graham: “Do things that don’t scale.” While it’s widely cited, the conversation rarely delves into the implementation of this advice in the realm of coding.
As I embark on my journey of building an AI podcast platform, I realized that an unscalable approach doesn’t have to equate to chaos or inefficiency. Over the past eight months, I’ve established a straightforward framework: every unscalable solution gets a lifespan of three months. By the end of this period, each project must either validate its worth and transition into a well-structured system or be phased out entirely.
This approach challenges the conventional engineering mindset that prioritizes scalable solutions from the outset. While it’s tempting to design intricate architectures capable of managing millions of users, such large-scale thinking can easily divert startups from their immediate goals. Often, optimizing for an audience that doesn’t yet exist leads to wasted time and resources. By adhering to my three-month guideline, I focus on developing straightforward, even “imperfect” code that pushes out real products and reveals actual user needs.
Current Infrastructure Strategies: Informal Yet Insightful
1. Consolidated Operations on a Single VM
Instead of distributing my database, web server, and background processes across multiple resources, I opt for a single $40/month virtual machine. It might sound risky, but this decision has provided invaluable insights into real resource needs. My initial assumption of needing a heavyweight architecture was disproven; my platform, despite its AI focus, functions comfortably with just 4GB of RAM. The complexities of a Kubernetes setup would have resulted in managing excess capacity for a problem that simply wasn’t there.
2. Simplistic Configuration Management
I’ve foregone the use of configuration files and environmental variables in favor of hardcoded constants throughout my codebase. While it may seem unorthodox, this approach lets me easily track changes in my code history and ensures that updates, albeit requiring a redeployment, are manageable and well-documented. Every adjustment has taken only moments rather than the weeks that a cohesive configuration service would demand.
3. Utilizing SQLite for a Multi-User Application
Instead of opting for a more traditional database like Postgres from the start, I’ve chosen SQLite to support my application’s needs—even with 50 concurrent users. This decision has illuminated my actual performance requirements, revealing that a
