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

In the tech world, there’s a well-known mantra from entrepreneur Paul Graham: “Do things that don’t scale.” While this advice is frequently quoted, the discussion often stops at the conceptual level, particularly when it comes to practical implementation in software development.

As an entrepreneur working on an AI podcast platform over the past eight months, I’ve established a unique framework that embraces this philosophy: any unscalable solution I implement is given a three-month trial period. At the end of this period, it must either demonstrate its value and warrant a more robust build, or it will be discarded.

Rethinking Scalability

Traditionally, as engineers, we are trained to prioritize scalable solutions right from the start. We often focus on intricate design patterns and architectural frameworks—microservices, distributed systems, and all the allure of handling millions of users. However, this is a perspective that suits larger enterprises more than it does startups.

In a startup environment, investing in scalability too early can often lead to inefficiencies and procrastination. It often involves optimizing for users who may not exist yet and solving potential issues that might never arise. My three-month rule compels me to write straightforward, albeit “imperfect,” code that can be deployed and tested in the real world. This approach allows me to truly understand user needs and behavior.

My Current Infrastructure Strategies

Here’s a glimpse of the unconventional approaches I’ve adopted and why they are surprisingly intelligent:

1. All Services on a Single VM

I began with a single $40/month virtual machine that hosts everything: database, web server, background jobs, and Redis. While this setup lacks redundancy and relies on manual backups, it has provided invaluable insights into my actual resource demands.

In just two months, I’ve learned that my platform requires only about 4GB of RAM, which means the complex Kubernetes infrastructure I once considered would have resulted in managing idle containers. Each crash—I’ve had two so far—has revealed unexpected vulnerabilities, teaching me precisely what needs attention.

2. Hardcoded Values Throughout

My configuration is straightforward—constants like pricing and user limits are hardcoded directly into the codebase. This may sound primitive, but it allows me to quickly locate and update values through a simple grep command and track every change in git history. In three months, I’ve only modified these constants three times, valuing a quick redeployment over a complex configuration