Embracing the 3-Month Rule: A Practical Approach to Engineering in Startups
In the startup world, the mantra “do things that don’t scale” is often echoed, most famously by Paul Graham. Yet, the challenge lies in applying this principle, especially when it comes to coding. After eight months of building my AI podcast platform, I’ve developed a straightforward framework to navigate this daunting task: every hack that doesn’t scale is given a lifespan of just three months. Following this period, I evaluate whether it adds value and requires proper development or if it’s time to phase it out.
As engineers, our instinct is to create “scalable” solutions from the get-go. We often design complex infrastructures—leveraging microservices, distributed systems, and other advanced architectures—to accommodate future users. However, in the startup arena, pursuing scalability too early can lead to costly delays, optimizing for hypothetical users and problems that may never arise. By adhering to my three-month rule, I focus on writing straightforward, albeit “imperfect,” code that gets deployed, helping me truly understand user needs.
Current Infrastructure Hacks: A Deep Dive
1. One VM to Rule Them All
By running my entire platform—database, web server, background jobs, and caching—on a single, economical $40/month virtual machine, I’ve gained invaluable insights into my actual resource requirements. With zero redundancy and manual backups, I quickly discovered that my supposedly “AI-heavy” platform rarely exceeded 4GB RAM. Instead of building a complex Kubernetes environment, I can directly observe what breaks during downtime, which is often a surprise.
2. Hardcoded Configuration Values
In my codebase, every configuration value—like pricing tiers and user limits—is hardcoded within the files. I’ve opted against separate config files or environment variables. While some may see this as a downside, I benefit from the simplicity: a quick search across my codebase for any configuration can be done in seconds. Each price adjustment is tracked in version control, allowing for efficient management. Spending 15 minutes redeploying is far more efficient than the hours it would take to implement a dedicated configuration service.
3. SQLite for Production Use
Yes, you read that right—I’m employing SQLite to handle my multi-user web application, a database that currently weighs in at a mere 47MB. Remarkably, it supports 50 concurrent users seamlessly. Through usage tracking, I found that my app
One Comment
This is a compelling approach that aligns well with the startup ethos of rapid iteration and learning through doing. Your three-month rule effectively encourages a focus on immediate value and real-world insights rather than prematurely optimizing for scale. I appreciate the emphasis on simplicity—using a single VM, hardcoded configs, and SQLite for production—all of which reduce complexity and accelerate deployment, allowing you to validate assumptions quickly.
One thing to consider as you evaluate these hacks over time is the potential need for incremental improvements once your user base grows or your product requires more robustness. For instance, while SQLite works well now, monitoring its performance and planning for a transition—perhaps to PostgreSQL—could help ensure scalability doesn’t become a bottleneck down the line. Similarly, exposing configuration values via environment variables instead of hardcoding might strike a good balance between simplicity and flexibility.
Overall, your framework exemplifies the value of pragmatic engineering—prioritizing learning and adaptation over premature perfection. It would be interesting to hear how you balance these quick hacks with the eventual need for more structured solutions as your platform matures.