Embracing the Non-Scalable: A 3-Month Experimentation Framework for Startups

In the startup world, Paul Graham’s advice to “do things that don’t scale” is often cited but seldom understood from a technical perspective. How should we truly apply this wisdom in coding and product development? After spending the last eight months building my AI podcast platform, I’ve devised a straightforward framework: each unscalable solution is given a trial period of three months. After this timeframe, we assess whether it has proven its worth or needs to be discarded.

Rethinking Scalability in Early Stages

As engineers, we are often conditioned to prioritize scalable solutions from the outset—implementing sophisticated architectures like microservices and distributed systems that can support millions of users. However, this mindset is more suitable for established companies. In the startup environment, focusing on scale can often lead to costly delays.

My three-month rule compels me to adopt a more pragmatic approach. Instead of aiming for perfection and scalability, I encourage myself to write straightforward, albeit imperfect, code that can be deployed quickly. This allows me to engage directly with user feedback and learn what they truly need from the platform.

Smart Infrastructure Choices

Here are some of my current infrastructure decisions that may seem unconventional but have provided invaluable insights:

1. Consolidated Infrastructure on a Single VM

I operate my entire application—including the database, web server, and background jobs—on a single $40/month virtual machine. This configuration lacks redundancy, and I handle backups manually. This approach has trained me to recognize my actual resource needs more effectively than any capacity planning report could. For instance, I’ve found that my platform requires only 4GB of RAM during peak usage. The complex Kubernetes architecture I almost implemented would have wasted resources managing idle containers.

2. Hardcoded Configuration Values

Instead of utilizing configuration files or environment variables, I’ve hardcoded key settings like pricing tiers and user limits directly into my code. While this may seem inefficient, the benefit lies in its simplicity: I can search my entire codebase in seconds for any configuration value, ensuring that changes are easily tracked. Given that I’ve only modified these configurations three times over three months, the time saved by not developing a dedicated configuration system is significant.

3. Using SQLite for Production

Surprisingly, I’ve chosen to run SQLite for my multi-user web application, which is only 47MB in size. It manages up to 50 concurrent