The 3-Month Experiment: A Pragmatic Approach to Non-Scalable Coding
In the world of startups, the mantra “Do things that don’t scale,” popularized by Paul Graham, is often quoted but seldom acted upon in the context of coding. After eight months of developing my AI podcast platform, I have developed a guiding principle around this concept: every unscalable approach gets a temporary life span of just three months. At the end of this period, each method either earns its place as a full-fledged solution or gets discarded.
As engineers, we have a natural inclination toward creating scalable solutions from the outset: designing intricate architectures with microservices, distributed systems, and sophisticated design patterns that can handle millions of users. However, this typically aligns more with large corporations than with startups, where scalable code can become an expensive form of procrastination. Often, we’re trying to optimize for user bases that are still on the horizon, tackling challenges that may never materialize. The three-month rule encourages me to produce straightforward, albeit imperfect, code that is quick to deploy and genuinely reflects user needs.
My Current Approaches: Simplicity in Action
Let’s explore some of my current infrastructure choices that may seem rudimentary but serve a strategic purpose:
1. Single VM Setup
Everything—database, web server, background jobs, and caching—runs on a single $40/month virtual machine. There’s no redundancy, and manual backups go straight to my local computer.
Why is this a smart strategy? In just two months, I’ve gained invaluable insights into my real resource needs, far more than any capacity planning document could provide. Surprisingly, my “AI-heavy” platform only peaks at 4GB of RAM. The complex Kubernetes setup I nearly initiated would have involved managing unnecessary containers. When crashes occur (and they have), the data reveals what genuinely goes wrong—often in ways I didn’t anticipate.
2. Hardcoded Variables
Constants like PRICE_TIER_1 = 9.99 and MAX_USERS = 100 are embedded throughout the code without any configuration files or environment variables. Deploying changes requires performing a redeployment.
The benefits? I can quickly search my entire codebase for configuration values. Each tweak is recorded in my Git history, and while every change might get code-reviewed by me, it simplifies oversight. Spending a week building a configuration service isn’t justified when I’ve only adjusted these values thrice in three months—result
One Comment
This approach of implementing the 3-month rule is a refreshing departure from the over-engineering often seen in early-stage startups. It emphasizes the importance of rapid iteration and learning from real-world usage rather than striving for perfect scalability upfront. Your example of a single VM setup and hardcoded variables illustrates that immediate clarity on resource utilization and straightforward code management can provide critical insights, enabling better-informed decisions down the line.
I especially appreciate how this pragmatic framework encourages prioritizing “just enough” solutions to validate assumptions quickly. It aligns well with the concept of technical debt being a strategic asset in the startup phase—used deliberately to accelerate learning. Have you considered documenting these experiments to track what approaches truly scale over time versus what remains sufficient as your platform grows? That could help refine the boundary where temporary solutions transition into more robust infrastructure.
Great insights!