The 3-Month Experiment: A Pragmatic Approach to Non-Scalable Solutions

In the startup landscape, the commonly echoed advice from Paul Graham to “do things that don’t scale” is often easier said than implemented, especially in coding. Having spent eight months constructing my AI podcast platform, I’ve developed an actionable framework for deploying such non-scalable tactics effectively: each of them is given a lifespan of three months. After this period, they must either demonstrate their worth and be properly restructured, or they are discarded.

As engineers, we are taught to prioritize scalable solutions from the outset, focusing on intricate design patterns and robust architectures capable of accommodating millions of users. This perspective, however, tends to align with larger corporations rather than startups where agility and quick iterations are crucial. In the early stages of a startup, striving for scalability can often lead to unnecessary expenses, as we may find ourselves optimizing for hypothetical users and nonexistent problems. My three-month framework compels me to implement straightforward, albeit “messy,” solutions that enable me to learn concretely about user needs.

Current Infrastructure Hacks: Simplifying for Learning

1. Single Virtual Machine for Everything

All essential components—including the database, web server, background jobs, and Redis—function on a single virtual machine costing $40 per month. There is no redundancy, and I perform manual backups.

The brilliance of this approach lies in its transparency: I’ve gleaned more insights about my resource utilization in two months than any capacity planning document could have revealed. Surprisingly, my resource-heavy AI platform only peaks at 4GB of RAM. The complex Kubernetes setup I nearly implemented would have been a burden, managing resources that would have remained unused.

When the system experiences an outage (which has happened twice), I gain genuine insights about failure points—often unexpected.

2. Hardcoded Configurations

Instead of employing config files and environment variables, I use hardcoded constants sprinkled through the code, such as:
python
PRICE_TIER_1 = 9.99
MAX_USERS = 100
Any modifications necessitate a redeployment.

The efficiency lies in the ability to quickly search any configuration value across my codebase. Changes to price points are traceable in git history, and each update—even if self-reviewed—ensures that I maintain control over my variables.

Creating a comprehensive configuration service could take a week. Yet, in the past three months, I’ve only updated these constants three times—