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
