The 3-Month Rule: A Pragmatic Approach to Building Your Startup
In the startup world, the phrase “Do things that don’t scale,” popularized by Paul Graham, is often repeated but rarely dissected in detail, especially from a technical perspective. After eight months of developing my AI podcast platform, I’ve come to adopt a unique framework I like to call the “3-Month Rule.” This principle allows unscalable hacks to thrive for three months, after which they either demonstrate their worth and evolve into permanent solutions, or they’re discarded.
The Startup Mindset: A Shift from Scalable Solutions
As software engineers, we’re often conditioned to prioritize scalable solutions right from the outset. With architectural patterns like microservices and distributed systems, it’s easy to get caught up in the allure of managing millions of users. However, in a startup environment, this approach can lead to inefficiencies as you’re essentially preparing for an audience that may not be there yet. My 3-Month Rule encourages me to write straightforward, albeit “imperfect,” code that allows for rapid deployment and critical user feedback.
Current Infrastructure Hacks: Lessons Learned
1. Unified Infrastructure on One VM
Instead of spreading resources across multiple servers or services, I’ve opted to run everything—from databases to web servers—on a single $40/month virtual machine. While this may seem risky, it has taught me invaluable lessons about my actual resource requirements. For example, I’ve found that my platform’s peak memory usage is just 4GB. Had I built a complex Kubernetes environment, I would have wasted resources managing containers that weren’t being utilized effectively.
Crashes (which have happened twice) provide crucial insights into real failure points, surprising me every time.
2. Hardcoded Configurations for Simplicity
I have opted for hardcoded values for configurations like pricing and limits, eliminating the need for complex config files or environment variables. This makes updates a breeze—just a quick redeploy, as opposed to the extensive time and effort that would come with building a configuration management service. In three months, I’ve adjusted configuration settings only three times, saving significant engineering hours.
3. SQLite: Surprisingly Effective
Surprisingly, I’ve employed SQLite for a web app that accommodates up to 50 concurrent users with impressive performance. By discovering that my app’s database access pattern consists of 95% reads, I now understand that starting with a more complex database solution like Postgres would have introduced unnecessary
One Comment
This is a compelling reflection on the value of embracing quick, unscalable solutions in the early stages of a startup. The “3-Month Rule” offers a pragmatic approach—allowing you to test assumptions rapidly and iterate based on real user feedback instead of over-investing in highly scalable but complex systems prematurely.
Your insights into infrastructure choices, such as consolidating everything on a single VM and opting for SQLite, highlight the importance of aligning technical decisions with current needs and avoiding over-engineering. This approach enables startups to be lean, learn quickly, and pivot effectively. I believe that maintaining this mindset—focusing on what works in the short term—can ultimately lead to more sustainable, scalable solutions as the product and user base grow.
Would be interesting to hear how you plan to transition from these initial hacks once the 3-month window closes. Do you have a framework for evolving these solutions into more robust systems without losing the startup agility?