Embracing the Unscalable: My 3-Month Experimentation Framework
In the startup world, you may have come across the well-known advice from Paul Graham: “Do things that don’t scale.” However, implementing this principle in the realm of coding is rarely discussed. After eight months of developing my AI podcast platform, I’ve crafted a straightforward framework to test unscalable hacks: each one gets a trial period of three months. After that time, if it proves its worth, we’ll build it out; if not, it gets cut.
As engineers, we are often conditioned to seek scalable solutions right from the beginning. We chase complex design patterns, incorporate microservices, and set up distributed systems—all to accommodate millions of users. While these approaches are vital for large corporations, they can be traps for startups.
In a nascent venture, aiming for scalability often leads to wasted time and resources, as we’re optimizing for future users who may never materialize. My three-month framework encourages me to produce straightforward, albeit “messy,” code that can be deployed quickly, allowing me to learn about genuine user needs.
Here are My Current Infrastructure Hacks and Why They’re Actually Beneficial:
1. Single Virtual Machine Setup
I’ve consolidated my database, web server, background tasks, and Redis onto a single virtual machine, costing just $40 a month. While this setup lacks redundancy and relies on manual backups, it has provided invaluable insights. Within just two months, I’ve gained a clearer understanding of my resource demands. My AI-heavy platform only requires 4GB of RAM at peak usage. The complex Kubernetes architecture I considered would have been an unnecessary management headache for empty containers.
When system failures—yes, there have been a couple—occur, I gather reliable data on what actually fails, which often surprises me.
2. Hardcoded Configuration
Instead of relying on config files or environment variables, I utilize constants spread across my files:
plaintext
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
This simplistic approach means I can search my codebase for configuration values in seconds. Each change is recorded in git history and subject to review—even if I’m the sole reviewer. While developing a configuration service could take a week, my three alterations in three months resulted in a mere 15 minutes of redeployment.
One Comment
This is a compelling approach that really underscores the value of rapid experimentation and learning early on in a startup’s lifecycle. Embracing “messy” solutions that are quick to deploy allows for real-world testing and user insights that abstracted or overly scalable architectures often delay. I particularly appreciate the emphasis on disciplined iteration—setting a three-month trial period for new ideas helps avoid paralysis by analysis and keeps the focus on what truly moves the needle.
Your example of consolidating infrastructure onto a single VM is a great reminder that, in the early stages, simplicity often leads to faster feedback cycles. It’s a strategic trade-off: accepting potential fragility for the chance to learn faster. As the platform matures and user demand increases, you can gradually introduce more scalable solutions when justified.
Additionally, the mindset behind using hardcoded configs for rapid iteration challenges the conventional wisdom that configuration management must always be complex. It’s a practical reminder that simplicity can be powerful when it serves to validate ideas quickly.
I’d be curious to hear how you plan to transition these “unscalable” hacks into more robust solutions once you’ve validated them. Do you have a framework for refactoring or scaling up once certain features or systems prove their value?