Embracing the 3-Month Rule: A Practical Approach to Experimentation in Development
The tech world is often rife with the advice to “do things that don’t scale,” a mantra coined by Paul Graham. However, many overlook the actionable steps to bring this ethos into the realm of coding. After dedicating eight months to creating my AI podcast platform, I’ve devised a straightforward framework centered around a simple yet powerful timeframe: every unscalable solution has a lifespan of three months. At the end of this period, these solutions face a critical decision: either they prove their worth and are developed further, or they are discarded.
As developers, there is a prevailing tendency to aspire toward building “scalable” infrastructures from the outset. We become enamored with architectural patterns, microservices, and distributed systems, all optimized for handling countless users. This mindset, however, is more suited to larger corporations than to the agile environment of a startup.
In a startup, the quest for scalability may very well serve as a catalyst for excessive delays—wasting precious time on problems that may never arise while missing opportunities that are present. My 3-month rule encourages me to create straightforward, even “imperfect,” code that is shipped quickly, allowing me to gain real insights into what users genuinely require.
Current Infrastructure Choices: Clever Hacks for Effective Learning
- Simplistic VM Deployment
All my components—database, web server, background jobs, and Redis—are hosted on a singular $40/month virtual machine. While this setup lacks redundancy and relies on manual backups, it has provided invaluable understanding of my true resource requirements in just two months. I’ve discovered that my “AI-intensive” platform only peaks at 4GB RAM usage. The complex Kubernetes architecture I nearly implemented would have merely been an exercise in managing unused containers. Each crash (yes, there have been two) yields essential data about real points of failure—often unexpected ones.
- Hardcoded Configuration Values
Instead of utilizing configuration files or environment variables, I keep constants directly within the codebase. This approach means that adjusting configuration values necessitates a redeployment, but it also enables me to swiftly search my entire code for any specific value within seconds. Changes are easily tracked in Git history and reviewed, reinforcing accountability in my process. Rather than spending a week developing a configuration service, I’ve only had to make three changes in three months—a significant time savings.
- SQLite in Production
My choice of SQLite
