Embracing the 3-Month Rule: A Pragmatic Approach to Development in Startups
In the realm of startup culture, the advice to “do things that don’t scale” from Paul Graham resonates strongly. However, the challenge often lies in practically applying this wisdom, especially when it comes to coding. After eight months of building my AI podcast platform, I’ve established a simple yet effective framework: any unscalable solution I implement is granted a lifespan of just three months. After this period, it must either prove its worth and be properly developed, or it will be discarded.
As engineers, our instincts drive us toward creating scalable solutions right from the start. We often find ourselves captivated by the allure of sophisticated architectural patterns such as microservices and distributed systems, all designed to accommodate millions of users. Yet, this mindset often belongs to larger organizations. In startups, prematurely investing time and resources into scalable code can lead to a costly form of procrastination. My three-month rule encourages me to embrace simplicity and focus on delivering straightforward, albeit imperfect, code that ultimately reveals the true needs of my users.
Current Infrastructure Insights: Smart Hacks for Real Learning
1. Using a Single Virtual Machine
Currently, my entire stack—database, web server, background jobs, and Redis—operates on a single $40/month virtual machine. While this approach lacks redundancy and relies on manual backups, it has imparted invaluable lessons about my actual resource requirements in just two months. I’ve discovered that my platform’s typical usage peaks at only 4GB of RAM. The complex Kubernetes setup I nearly implemented would have involved managing resources I’ve yet to use!
Moreover, each time the system crashes—which has happened twice—I gain critical insight into the underlying issues, which are rarely what I anticipated.
2. Hardcoded Configurations
I utilize hardcoded constants throughout my codebase for configuration settings. Changes necessitate a quick redeployment instead of cumbersome configuration management files or environment variables. This method has its advantages; I can instantly reference any configuration value using simple search commands, and every adjustment is logged in version control.
Instead of dedicating a week to constructing a configuration service, I’ve made just three changes in three months, translating to approximately 15 minutes of redeployment over 40 hours of theoretical engineering.
3. Leveraging SQLite in Production
Yes, I’m currently employing SQLite for my multi-user web application, and it performs exceptionally well with a 47MB database accommodating up to
One Comment
This is a compelling approach that highlights the value of rapid iteration and learning through simplicity—especially in the early stages of a startup. Your 3-month rule effectively encourages experimentation without over-investing in scalable solutions prematurely, which is often a significant pitfall for young teams. I particularly appreciate how you’ve embraced lightweight infrastructure choices, like running everything on a single VM and leveraging SQLite, to gain real-world insights before scaling.
This approach reminds me of the principle of building the *”minimum viable”* version that reveals actual user needs, then iterating accordingly. It also underscores the importance of conscious trade-offs—accepting some manual processes and limited redundancy early on can accelerate learning and reduce wasted effort.
Have you considered integrating a retrospective habit at the end of each three-month cycle? This could help systematically evaluate which aspects of your initial solutions are worth scaling up and which can be replaced altogether. Ultimately, your framework illustrates that thoughtful, short-term experimentation can significantly inform long-term architecture decisions in a startup context. Looking forward to seeing how this strategy evolves!