Embracing Unconventional Development: The 3-Month Rule for Startups

In the world of startups, the advice from Paul Graham to “do things that don’t scale” often serves as a guideline. However, few articles dive into how to effectively implement this concept in the realm of coding and engineering. Having worked on my AI podcast platform for the past eight months, I stumbled upon a strategy that has proven beneficial: I give every temporary, unscalable solution just three months to demonstrate its value before deciding whether to adopt it permanently or let it go.

The Importance of Flexibility in Startups

As engineers, we are conditioned to focus on scalable solutions from the outset. We envision elaborate architectural models that can accommodate millions of users, utilizing design patterns, microservices, and distributed systems. Such thinking is typical of established companies, yet, in a startup environment, obsessing over scalable code can often be a form of procrastination.

Instead of focusing on hypothetical users and problems, my three-month rule encourages the development of straightforward, adaptive, and imperfect code that can be deployed quickly. This approach allows me to discover what users genuinely need rather than what I presuppose they might want.

Current Infrastructure Innovations: Practical and Insightful

Here are some of the unconventional strategies I’ve employed, each designed to maximize learning rather than optimize too soon.

1. Consolidated Operations on One Virtual Machine

Instead of distributing components across multiple servers, I run everything—from the database to background jobs—on a single virtual machine, costing just $40 per month. While this means I have no redundancy and my backup is manual, this setup has allowed me to gain invaluable insights about my actual resource usage far more effectively than any overly detailed planning document could provide.

For instance, my platform’s peak memory usage has only reached 4GB, highlighting that my initial plans for a complex Kubernetes setup would have led to unnecessary overhead.

2. Hardcoded Configuration Values

Instead of incorporating lengthy configuration management solutions, I use hardcoded constants throughout my codebase. When I need to make updates, it involves a straightforward process of redeployment. This method allows me to quickly track configuration changes and maintain a clean version history in git—an immense time-saver when compared to building a dedicated configuration service.

3. Utilizing SQLite in a Production Environment

Even though my multi-user application operates on SQLite with a database size of just 47MB, it successfully manages up