Embracing the 3-Month Experimentation Rule: A Framework for Agile Development
In the world of tech startups, the age-old advice from entrepreneur Paul Graham resonates deeply: “Do things that don’t scale.” However, the question remains – how can we effectively integrate this principle into our coding practices? After eight months of building an AI podcast platform, I’ve created a straightforward strategy: every unscalable hack has a lifespan of just three months. At the end of this period, we assess its worth; either it is further developed and optimized, or it is discarded.
As engineers, we often approach problems with a desire to create scalable solutions right from the outset. We indulge in sophisticated design patterns and microservices architectures aimed at accommodating vast user bases. While such approaches are ideal for established companies, they can often lead to unnecessary delays and complexities in a startup environment. My personal 3-month rule encourages me to prioritize straightforward, even “imperfect,” code that delivers results and clarifies user needs.
Current Infrastructure Hacks: Practical Learning in Action
1. Single VM Deployment
My entire tech stack, from the database and web server to background jobs, operates on a single $40/month virtual machine (VM). While there’s no redundancy and backups are done manually, this setup has provided invaluable insights. In just two months, I’ve accurately gauged my resource requirements, discovering that my platform only peaks at 4GB of RAM. The complex Kubernetes architecture I almost implemented would have simply involved managing empty containers. When system crashes occur (which they have, twice), the data reveals unexpected points of failure, fostering a deeper understanding of my infrastructure.
2. Hardcoded Configuration
My configuration is straightforward: constants like PRICE_TIER_1 = 9.99 and MAX_USERS = 100 are scattered throughout the codebase without the use of external config files or environment variables. Although changing a value necessitates redeployment, this method allows me to find any configuration in mere seconds. Each price adjustment is documented in version control, creating complete transparency over changes. Instead of spending a week developing a dedicated configuration service, I’ve relegated changes to a mere 15-minute redeployment on average.
3. SQLite in Production
Yes, I’ve chosen SQLite for my multi-user application, with a database size of just 47MB supporting 50 concurrent users effortlessly. This choice has illuminated my access patterns, which are predominantly reads. Had I launched with
