Embracing the 3-Month Rule: A Pragmatic Approach to Non-Scalable Solutions
In the startup realm, the commonly shared wisdom from Paul Graham is to “do things that don’t scale.” Yet, when it comes to implementation, especially within the technical landscape, many find themselves at a loss. After eight months of developing my AI podcast platform, I stumbled upon a straightforward methodology: subject every non-scalable hack to a three-month evaluation period. At the end of this timeframe, each approach must either demonstrate its worth and transform into a more sustainable model, or it will be discarded.
Traditionally, engineers are conditioned to prioritize scalable solutions right from the outset. We often immerse ourselves in creating sophisticated architectures such as microservices, distributed systems, and other design frameworks capable of accommodating millions of users. However, this mindset is often more suited for larger companies than for nimble startups.
In the context of a startup, focusing on scalability too early can equate to costly delays. We may find ourselves optimizing for hypothetical users and addressing challenges that may never arise. By adhering to my 3-month rule, I am encouraged to develop straightforward, albeit imperfect, code that gets shipped quickly, allowing me to gain insights into what users truly want.
Key Infrastructure Decisions: Insights from My Current Hacks
- Centralized Operations on a Single Virtual Machine
My entire platform runs on a single virtual machine, encompassing everything from the database to web operations and background tasks. While this setup lacks redundancy and relies on manual backups, it has granted me invaluable insights into my actual resource demands. In just two months, I discovered that my platform’s resource utilization significantly peaked at 4GB of RAM. Had I opted for a complex Kubernetes architecture, I would have found myself maintaining unused containers.
The occasional crashes (twice so far) have provided tangible data on failure points—never where I anticipated.
- Hardcoded Configurations
Instead of utilizing configuration files or environment variables, I’ve chosen to hardcode my settings directly into the codebase. This may seem archaic, but the advantage lies in its simplicity: I can swiftly search for any configuration value across my code. My price adjustments are tracked in version control, and I handle updates via code reviews—even if they involve reviewing my own pull requests.
This setup has proven efficient; the time spent redeploying to make changes is negligible compared to the hours required to build a comprehensive configuration service.
