The 3-Month Framework: Embracing Imperfection in Tech Development

In the tech world, we’re often reminded by figures like Paul Graham to “do things that don’t scale.” Yet, the challenge lies not in the advice itself but in its application—especially when it comes to coding.

After eight months of developing my AI podcast platform, I’ve crafted a straightforward methodology: each non-scalable solution receives a testing period of three months. At the end of this timeframe, the solution either demonstrates its value and gets the structured support it deserves, or it is discarded.

As developers, we’re typically conditioned to create scalable architectures from the outset. We focus on sophisticated design patterns, utilizing microservices and distributed systems—all of which are fantastic for handling large user bases. However, this mindset often leads startups down the path of costly indecision. We find ourselves optimizing for potential users who may never come and tackling problems that might never arise. My three-month framework compels me to produce straightforward and often “subpar” code that is deployed quickly, enabling me to better understand the needs of my users.

Current Hacks in My Development Process and Their Value

1. Consolidation on a Single Virtual Machine

Currently, my entire stack—database, web server, background jobs, and caching—is running on one $40/month virtual machine. This setup lacks redundancy and relies on manual backups.

Why is this a smart move? In just two months, I’ve gained valuable insights into my resource consumption that no capacity planning document could provide. My “AI-intensive” platform peaks at a mere 4GB of RAM. The elaborate Kubernetes setup I almost implemented would have resulted in managing empty containers. Each crash (and there have been a couple) has revealed exactly what fails, which often surprises me.

2. Utilizing Hardcoded Configurations

My configuration looks like this:

python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"

No separate configuration files or environment variables—just hardcoded values spread throughout the code. Any adjustment necessitates a redeployment.

This approach has unexpected advantages: I can quickly search through my entire codebase for configuration values. Changes are logged in git history, and despite being a solo reviewer, I still ensure every value is considered.

Spending a week building a dedicated configuration service would have been overkill.