Embracing the 3-Month Rule: A Pragmatic Approach to Unscalable Solutions
In the world of startups, the wisdom of Paul Graham’s advice, “Do things that don’t scale,” is widely acknowledged yet often challenging to execute effectively, particularly within the realms of coding and development. As I navigate the journey of building my AI podcast platform over the past eight months, I’ve instituted a straightforward yet impactful framework: any unscalable technique I implement gets a lifespan of just three months. If it proves its worth, it gets a robust implementation; if not, it gets the ax.
The Dilemma of Scalable Solutions
As software engineers, we often aim to architect solutions designed for scalability right from the start—think sleek microservices, sophisticated distributed systems, and complex design patterns that can cater to millions of users. However, this mindset is typically suited for established companies, while in the startup landscape, focusing on scalability can sometimes equate to costly procrastination. By anticipating future user demands that may never materialize, we risk devoting time to issues that don’t yet exist.
My three-month rule incentivizes me to develop straightforward, sometimes “imperfect” code that can be quickly deployed. This approach not only leads to tangible results but also illuminates the actual needs and behaviors of users.
Current Infrastructure Hacks: A Smart Approach to Learning
1. Single-VM Architecture
Currently, everything—including my database, web server, background jobs, and Redis functions—operates on a single $40 monthly VM with no redundancy and manual backup systems. While this setup might seem rudimentary, it has allowed me to gain a deeper understanding of my resource requirements within a mere two months. Interestingly, my “AI-focused” platform only peaks at 4GB of RAM, revealing that the intricate Kubernetes architecture I almost implemented would have had me managing empty containers instead.
2. Hardcoded Configurations
Instead of using configuration files or environment variables, I’ve scattered constants across my codebase:
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
While this might seem like a lack of organization, it allows me to quickly search my entire codebase for any configuration value and track changes effortlessly through git. Redesigning a configuration service would necessitate substantial effort, yet I’ve only tweaked these
One Comment
Great insights! Embracing the 3-month rule is a powerful way to balance agility and learning, especially in the early stages of a startup. Your emphasis on rapid iteration and avoiding over-engineering aligns well with the thesis that “done is better than perfect” — especially when the goal is to validate assumptions quickly.
I appreciate how your approach encourages us to focus on real user feedback rather than speculative scalability worries. It’s also a reminder that sometimes, simplicity and honesty in infrastructure—like your single-VM setup and hardcoded configs—can be invaluable for understanding underlying needs before investing in more complex solutions.
Have you found specific signals within this timeframe that reliably indicate whether a feature or infrastructure hack should be scaled or abandoned? It would be interesting to hear how you measure and interpret success or failure in this agile context. Thanks for sharing your pragmatic approach!