Embracing the 3-Month Rule: A Practical Approach to Non-Scalable Solutions in Tech
In the tech world, especially in startups, you might have heard the phrase popularized by Paul Graham: “Do things that don’t scale.” While this advice is often circulated, few delve into the practical application of this mindset, particularly in software development. After eight months of building my AI podcast platform, I’ve adopted a straightforward yet effective framework inspired by this principle: any hack that isn’t scalable has three months to demonstrate its value. Post this period, it either evolves into a more robust solution or is discarded altogether.
As engineers, we often find ourselves gravitating towards scalable solutions—envisioning microservices and distributed systems prepared to accommodate millions of users. But in a startup environment, over-optimizing for potential users often leads to wasted resources and missed learning opportunities. My rule encourages me to write straightforward, even “imperfect” code that can be deployed quickly, allowing me to gain insight into what my users truly require.
Current Infrastructure Strategies That Work
1. Single-VM Architecture
I’m currently running my entire stack—including the database, web server, background jobs, and Redis—on a single $40/month virtual machine. While this setup lacks redundancy and relies on manual backups to my local machine, it has provided me with invaluable knowledge about my actual resource requirements. Surprisingly, my platform only peaks at around 4GB of RAM, revealing that the complicated Kubernetes setup I nearly pursued would have been unnecessarily complex. Moreover, each crash has delivered practical data regarding system failures, which were often unforeseen.
2. Hardcoded Configurations
With constants hardcoded throughout my codebase—such as pricing tiers and user limits—I simplify management and deployment. Modifying any configuration necessitates a redeployment, but this has proven efficient. I can quickly search for specific values across all files, and every change is documented in my git history. In three months, I’ve altered configurations just three times, saving countless hours of potential engineering time.
3. Using SQLite in Production
Yes, my multi-user application employs SQLite, and it functions well with a database size of merely 47MB. This choice surfaced from an analysis showing that 95% of my access patterns are read operations. Had I set up a more robust database solution like Postgres from the start, I would have been wasting efforts on optimization for a situation that simply
One Comment
Thank you for sharing your pragmatic approach to embracing non-scalable solutions during the early stages of your startup. I really appreciate how you’ve structured your “3-Month Rule” to balance speed and learning, allowing for rapid iteration without getting bogged down by over-engineering.
Your choice to start with simple, manageable setups—like a single VM and SQLite—highlights a critical mindset: prioritize learning about actual user behavior and system demands over premature optimization. This approach not only conserves resources but also provides invaluable insights that inform future scaling decisions.
I think your strategy aligns well with the Lean Startup methodology—focusing on validated learning before committing to complex, scalable architectures. It’s also a reminder that in startup environments, agility and adaptability often outweigh technical perfection, especially in the initial phases.
Looking forward, it will be interesting to see how you evolve your infrastructure as user demand grows, perhaps transitioning gradually to more scalable solutions only when justified. Thanks again for sharing your experience—it’s inspiring and offers practical guidance for engineers navigating the delicate balance between speed and scalability.