Embracing the Three-Month Experiment: A Framework for Lean Development
In the tech world, you’re likely familiar with Paul Graham’s well-known mantra: “Do things that don’t scale.” While the principle is widely acknowledged, the implementation in coding often goes unexplored. Over the past eight months developing my AI podcast platform, I’ve identified a practical approach: any non-scalable hack in my code has a lifespan of just three months. After that, it either substantiates its value and receives the necessary upgrades or it gets phased out.
The Startup Perspective: Avoiding Perfectionism
As engineers, we are taught to focus on scalable solutions from the outset. We find ourselves navigating complex architectures like microservices and distributed systems, designed to accommodate millions of users. However, this big-company mentality often leads to wasted resources in the startup environment. The truth is that scalable infrastructure can sometimes act as a costly form of procrastination—optimizing for potential users who may never materialize and solving problems that aren’t urgent.
My three-month framework compels me to write straightforward, albeit imperfect, code that yields immediate results and teaches me valuable insights about user needs.
My Pragmatic Technical Approach
1. Single Virtual Machine Setup
My entire infrastructure—comprising the database, web server, background jobs, and Redis—operates on a single $40/month virtual machine (VM). While this may seem risky with zero redundancy and manual backups, this setup has provided invaluable insights. Within just two months, I discovered that my “AI-heavy” platform peaks at 4GB RAM, information that would have been obscured by an elaborate Kubernetes architecture.
When the system crashes, which has happened twice, I gain crucial data about failures—prompting revelations that often surprise me.
2. Hardcoded Configurations
I rely on hardcoded constants for critical configurations, such as:
plaintext
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
Having no configuration files or environment variables simplifies changes, requiring only a redeployment with a concise command. I’ve revised these values just three times in three months—spending a mere 15 minutes redeploying compared to the 40 hours it would have taken to build an elaborate configuration management system.
3. SQLite for Production
Running SQLite for a multi-user web application, with a
One Comment
Thank you for sharing these practical insights into your lean development framework. I appreciate how embracing the “do things that don’t scale” mentality allows for rapid learning and iteration—especially in startup contexts where time and resources are limited. Your approach to limiting hacks to a three-month lifespan introduces a healthy discipline of reassessment, ensuring that quick solutions either evolve meaningfully or are phased out efficiently.
The single VM setup and reliance on hardcoded configurations are compelling because they prioritize speed and simplicity over initial robustness, which can be a game-changer when validating ideas early on. Your decision to use SQLite in production, despite potential scalability concerns, underscores the value of tailoring infrastructure choices to the current needs rather than preemptively optimizing for scale.
One aspect to consider as your project grows is establishing clear revisit points for these “hack” solutions. When certain elements consistently prove valuable or become bottlenecks, integrating them into a more scalable, maintainable architecture can be a natural evolution—guided by data and actual user growth rather than assumptions.
Your methodology demonstrates an effective balance between pragmatism and strategic planning—an approach many early-stage startups could benefit from adopting. Thanks again for sharing—this is a great reminder that sometimes, less pretension and more speed can accelerate learning significantly.