Embracing the 3-Month Rule: A Pragmatic Approach to Unscalable Solutions
In the world of startups, sage advice abounds. One popular nugget comes from entrepreneur Paul Graham: “Do things that don’t scale.” However, one seldom-discussed aspect is how to actually implement this notion in a coding environment.
Having spent the past eight months developing an AI podcast platform, I’ve created a streamlined strategy: every unscalable approach I deploy is designated a lifespan of three months. After this period, if it demonstrates its worth, it transitions into a more robust solution; if not, it’s time to move on.
As engineers, we’re often conditioned to prioritize scalable solutions right from the outset. We aspire to create intricate systems with microservices, design patterns, and robust architectures capable of serving millions. Yet, this mindset often belongs to larger companies with established user bases.
In the startup arena, investing time and resources into scalable code can be a costly delay. Frequently, we are preemptively tackling issues for a user base that doesn’t yet exist. By adhering to my three-month rule, I’m encouraged to write simpler, more straightforward code that may not follow best practices but allows for rapid deployment and valuable user insight.
My Key Infrastructure Approaches: Why They Work Wonders
1. Single Virtual Machine Hosting
I run all my services—database, web server, background tasks, and caching—on one $40/month Virtual Machine without redundancy and depend solely on manual backups.
This seemingly reckless setup has proven to be unexpectedly insightful. In just two months, I’ve gained a far clearer picture of my actual resource requirements than any capacity planning documents could have provided. I discovered that my AI-driven platform only peaks at 4GB of RAM. The complex Kubernetes architecture I almost implemented would have merely managed idle containers.
Whenever the system crashes (which it has twice), I receive tangible insights on what specifically causes the issues—often surprising me.
2. Hardcoded Configuration Values
In my coding ecosystem, values like pricing tiers and user caps are hardcoded directly within the files. There are no separate configuration files or environment variables to worry about.
The brilliance of this lies in its simplicity. I can swiftly search my entire codebase for any configuration detail. Every price adjustment is documented through version control, allowing for straightforward tracking. The time spent changing these values is minimal when compared to the lengthy overhaul that implementing a configuration service would require.
