Embracing the Three-Month Test: A Pragmatic Approach to Unscalable Solutions
When it comes to startup development, advice from influential figures like Paul Graham often resonates deeply: “Do things that don’t scale.” However, the challenge lies in translating this concept into actionable strategies, especially within the realm of coding. After eight months of building my AI podcast platform, I’ve established a straightforward but effective framework: every temporary, unscalable solution is given a lifespan of three months. At the end of this period, these hacks either prove their worth and undergo proper development or are discarded.
As engineers, our education emphasizes crafting scalable solutions from the outset. We’re trained to embrace complex architecture—think design patterns, microservices, and distributed systems—all of which cater to millions of users. While this mindset is essential for large companies, in a startup, it can often amount to costly procrastination. We end up optimizing for hypothetical users and addressing issues that might never arise. My three-month rule compels me to write straightforward, albeit “imperfect” code that can swiftly launch, providing genuine insights into user needs.
My Current Infrastructure Strategies: Learning Through Pragmatism
1. Consolidated Operations on a Single Virtual Machine
By running my database, web server, background jobs, and Redis on a single $40/month VM, I’ve adopted an intentionally basic infrastructure setup. While lacking redundancy and relying on manual backups to my local system may seem reckless, it has led to a profound understanding of my actual resource requirements within just two months. My “AI-focused” platform occasionally spikes at 4GB of RAM—a stark contrast to the intricate Kubernetes infrastructure I nearly implemented. This simple setup has given me invaluable data on failure points during crashes (which have occurred twice), revealing unexpected vulnerabilities.
2. Hardcoded Configuration Throughout
Utilizing hardcoded constants like:
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
rather than configuration files or environment variables may appear simplistic, but it has its advantages. With this method, I can perform quick searches across my codebase for any configuration value, and I meticulously track changes through version control. This approach eliminates the need to dedicate a week to creating a configuration service; the three changes I’ve made in three months have required a mere 15 minutes of redeployment.
One Comment
Thank you for sharing your practical approach to balancing speed and scalability during early startup phases. Your three-month rule provides a clear framework for validating ideas without over-investing in unproven solutions. I particularly appreciate the emphasis on learning through simplicity—running everything on a single VM and hardcoding configurations can indeed accelerate iteration and understanding, especially when resources and time are limited.
One potential extension of this approach is gradually introducing layered complexity as user data and product-market fit become clearer. For example, after validating core features via your three-month cycles, you might start transitioning critical components to more scalable architectures, like containerization or externalized configurations, to support growth without sacrificing the agility you’ve cultivated.
Ultimately, your methodology reminds us that engineering is as much about informed experimentation as it is about technical perfection—adapting infrastructure and code to real-world needs while maintaining a pragmatic mindset. Looking forward to seeing how your platform evolves!