Embracing the Unscalable: My Framework for Agile Development
In the world of startups and innovation, we often hear the mantra from Paul Graham: “Do things that don’t scale.” While this advice is widely acknowledged, the challenge lies in its practical application—especially in the realm of software development.
Over the past eight months, as I’ve been working on my AI podcast platform, I’ve devised a straightforward yet effective framework: every unscalable approach I implement has a lifespan of just three months. After this period, these methods are assessed for their value and either refined for permanence or discarded.
As engineers, we often fall into the trap of designing for scale from the outset—crafting intricate architectures that are capable of accommodating millions of users. This approach, while appealing, is more fitting for larger corporations. In the startup environment, focusing on scalability too early can be a costly form of procrastination.
My three-month rule encourages me to prioritize simplicity and directness. It compels me to write code that may not be elegant but is highly functional, providing real insights into what users truly need.
My Strategic Infrastructure Decisions: Insights from Current Practices
1. Consolidated Resources on a Single VM
Currently, my entire application’s infrastructure—including the database, web server, background jobs, and Redis—is hosted on a single virtual machine costing $40 a month. This setup offers no redundancy and utilizes manual backups to my local machine.
Why is this approach advantageous? Within just two months, I’ve gained unparalleled insight into my actual resource requirements—insights that no amount of capacity planning documents could offer. For instance, my AI-driven platform only peaks at 4GB of RAM. Investing time in a complex Kubernetes setup would have been unnecessary and a waste of resources.
When crashes occur (as they have, twice), they provide crucial data about the vulnerabilities in my system, which are often not where I anticipated.
2. Hardcoded Configuration
My configuration settings—for example, pricing and user limits—are hardcoded directly within the codebase, as opposed to being managed in config files or environment variables.
This setup grants me a unique advantage: I can quickly search and track every configuration value throughout my codebase. Changes are minimal—I’ve altered these specific settings only three times over the last three months—translating to a mere 15 minutes of redeployment instead of the potential 40 hours spent building a configuration service.
