The 3-Month Experiment: A Pragmatic Approach to Non-Scalable Solutions
When embarking on the journey of building a startup, one advice stands out from esteemed entrepreneur Paul Graham: “Do things that don’t scale.” Though many acknowledge this wisdom, few delve into how to operationalize it within the realm of coding. After dedicating eight months to developing my AI podcast platform, I’ve devised a straightforward yet effective strategy: each non-scalable hack gets a lifespan of three months. At the end of this period, we evaluate its utility – either it gets transformed into a robust system or it’s discarded.
Traditionally, engineers tend to focus on crafting scalable solutions right from the outset. The allure of comprehensive design patterns, microservices, and distributed architectures often overshadows simpler alternatives that can serve us better in the early stages of development. In a startup environment, pursuing scalability can often be a costly form of procrastination; we spend time and resources optimizing for potential users who may never materialize while neglecting current, pressing user needs. My three-month timeframe encourages creating basic, effective, and sometimes “imperfect” code that delivers real insights about user behavior and requirements.
Current Hacks and Their Merits
1. Single-Server Setup
At present, my application’s entire architecture—database, web server, background jobs, and caching—operates from a solitary $40/month virtual machine (VM). This approach, devoid of redundancies and reliant on manual backups, has proven more insightful than extensive capacity planning could ever be. Within just two months, I have grasped my actual resource needs; my supposedly “AI-heavy” platform only draws upon 4GB of RAM during peak use. The sophisticated Kubernetes infrastructure I nearly deployed would have ended up managing idle containers. When outages occur, I gain valuable insights into failure points—insights that often surprise me.
2. Directly Hardcoded Constants
In terms of configuration, I predominately utilize hardcoded constants scattered throughout the codebase—for example, tier pricing and user limits. While this might seem inefficient, it grants me the ability to swiftly search through my code for any configuration value, and each adjustment is coupled with immediate redeployment. Over the past three months, I’ve made only a handful of configuration changes, which equates to a mere 15 minutes of redeployment time compared to the potential 40 hours that a dedicated configuration management service would demand.
**3. SQLite as the Database
