Build Small Things
The more complex a project is, the more likely it is to fail.
The data clearly confirms it, but if you've spent any time in software development you just know this is true. We can feel the uncomfortable and inevitable words being spoken: "I'm sorry but it was just a lot more complicated than we originally thought". Let's be clear, this problem is extremely costly, it's endemic and it's not improving. The solutions we have today; the catch-all that is "agile", is far from perfect. AI agents are not going to save us.
Build Small Things is the foundational principle that explains why software development succeeds or fails. Every failure can be traced to complexity. Every success can be traced to simplicity.
This simple yet radical approach applies in a multiplicity of arenas. Project planning. Product iteration. Process design. Code organization. Individual work patterns. The same principle that makes a single line of code safe to deploy makes a small project succeed. The same principle that makes a simple system maintainable makes a simple process efficient.
Complexity fails. Simplicity wins. This is true at every level, from a hobby project to a global enterprise architecture.
This isn't just a theory. As a technical leader who's been in the guts of everything from seed-stage startups to hyper-growth unicorns, I've seen that the most common culprit for sluggish development, off-track projects, or projects that never see release day isn't technical debt or a lack of talent. It's the process itself. It’s the very structure we use to think about and practice our work.
Software empowers people, it makes their lives better. It allows us to do remarkable computational things that our brains are ill-equipped to do on their own. To work in software is to improve the lives of those around us. When we can make small improvements to the lives of those people on a daily basis the cumulative impact is profound. Results are constant, impactful and are measured in real time, not quarterly. This requires a different way of thinking. This requires embarking on simple projects with clear goals. This requires writing code that's simple to reason about. This requires full understanding on the "why" behind the "how".
Build Small Things is the alternative to Big Project Syndrome complexity. We don't escape complexity with more process, more ceremonies, or more management. We escape it by making today's fear-based process irrelevant. We ship constantly. We integrate consistently. We discuss continuously. We build a system so fluid and resilient that the bureaucratic rituals of "Agile" look as foolish and outdated as they actually are.
We expect problems to occur. We have the levers to fix things instantly, because we allow for a system that can often bend and sometimes break. Instead of investing in the theater of sprint planning, we invest in a resilient deployment system that makes shipping code, and fixing it, instant, safe, and above all, expected. We escape the giant, terrifying releases trapped in a sprint-first architecture by making releases so small and frequent they become non-events.
Build Small Things isn't just about code. It's about projects that can ship in days, not months. It's about processes that enable real organizational change, not ceremonies that create delays. It's about individual engineers committing hourly, not weekly. It's about organizations that eliminate complexity, not manage it. It's about inspiring those of us who work in software development to say "I built something worthwhile today" and those of us that use software to become active participants in it.
This manifesto shows you how.
The Trap: The Two-Week Prison
Your process is either generating value or it's generating overhead. There is no neutral state. As engineering teams grow, we instinctively pile on process to compensate for the natural erosion of interpersonal trust and the rising cost of failure. But every step added, every new ceremony, introduces latency. It creates task-switching costs. It turns a lean operation into a bureaucracy, one Jira ticket at a time.
A sprint is a time-box. A deadline. And deadlines are where good engineering goes to die. The entire structure encourages you to batch up work, creating large, complex pull requests that are hell to review and even harder to merge. The need to "finish the sprint" leads to cutting corners and accumulating the very technical debt the process was supposed to prevent.
Think about what we try and cram into that two-week box. A Product Requirements Document has to be written. The work has to be prioritized against a dozen other screaming emergencies. UX has to design it. The team has to groom it. Then, and only then, can it be built and tested. We've taken the entire, lumbering waterfall process and simply chopped it into two-week chunks, pretending it's agile. It's a theatrical performance of productivity, where the main output isn't working software, but the successful completion of the ceremony itself.
Worse, it creates a built-in delay machine. A simple request made on day two of a sprint gets the dreaded reply: "We'll get it in the next sprint." Let's do the math on that. The current sprint has to finish (two weeks). The next sprint has to be planned and completed (another two weeks). Then the code has to be tested and deployed. A simple, one-line change can easily take over a month to reach a customer. If you're lucky. This is the opposite of agile.
These "best practices" are the very things that create a self-fulfilling prophecy of slowness. When speed drops, what do we do? We add more process—more SCRUM, more testing, more review—to compensate. This, of course, further slows the team. The sprint cycle itself trains engineers to think in large, slow batches. Why ship a one-line fix today when you can bundle it into the grand, two-week release? This inevitably leads to enormous, multi-file pull requests that are impossible to review, riddled with merge conflicts, and terrifying to deploy. It is a spiral into inefficiency and shattered morale.
While SCRUM, large PRs, and lengthy UAT are all on the list of rituals you should re-evaluate, there is one structure that is almost universally misused in high-growth companies: the dedicated Staging Environment and its fixed Sprint Release cycle.
In a startup desperately trying to find product-market fit, a lengthy, multi-step process for releasing code is poison. The delay between code completion and user validation is pure capital risk. Holding onto finished code for a multi-day review, merging it into a complex staging environment, and subjecting it to ceremonial testing is a luxury you cannot afford. It is simply too expensive.
The sprint necessitates a whole ecosystem of waste. It demands a persistent staging environment where finished code sits and rots, waiting for a ceremonial release day. It creates a fixed-cadence release cycle that is completely decoupled from business needs. In a startup desperately trying to find product-market fit, this is poison. The delay between code completion and user validation is pure capital risk. Holding onto finished code for a multi-day review and a multi-week sprint cycle is a luxury you cannot afford.
The single most dangerous structural dependency you can have is the fixed-cadence, gate-checked Sprint Release.
Velocity is a Function of Risk Tolerance
Why did the hyper-growth teams I ran at Gopuff operate without these typical dependencies? No sprints, no tickets, code shipped directly to prod. Because our operational goals defined an entirely different Risk vs. Velocity calculation. The CTO's job is not to eliminate risk; it's to choose the right risks to take.
I map every organization on a Risk vs Velocity plot. Seed-stage, Sinclair in 1981, and Gopuff in 2019 sit up and to the right. Nuclear plant software sits on the floor. Gopuff in 2023 had already slid back toward enterprise.
Four quadrants. Only one of them is a place you survive early.
- Fragile (high risk, low velocity): you take the damage and still cannot ship.
- Stagnant (low risk, low velocity): enterprise. Nothing breaks because nothing changes.
- Fluid (high risk, high velocity): seed, Sinclair, early Gopuff. Brittle systems, tests optional, shipping is immediate. This is where you survive.
- Efficient (low risk, high velocity): the quadrant people pretend they occupy. You earn it later, after the architecture can absorb failure.
The job is not to live in Efficient on day one. The job is to pick a sweet spot under your actual risk tolerance.
The dependencies you skip are the ones that yank a growth company out of Fluid and into Stagnant before the money warrants it.
For a company fighting for product-market fit, the financial cost of losing two days of velocity to a review/staging/sprint process far outweighs the cost of a temporary bug in production. You are trading precious Time to Market for an illusion of safety. The true strategic value in the early days is validating your assumptions faster than your burn rate depletes your cash.
Every Agile ritual that slows down the clock—and the sprint is the master clock—accelerates the Days Until Bankruptcy counter.
The Way Out: Velocity as a System
So you want to skip the traditional dependencies without everything catching fire? You must replace Process-based Risk Mitigation with Structural & Cultural Risk Mitigation.
1. Architect for Speed with Tiny, Atomic Units
You can't ship a massive, 100-file PR straight to production. But you can eliminate the need for it.
- Commit small and often. Every commit should do one thing and one thing only.
- Pair on everything. This used to mean two humans. In the age of AI, it means a human-AI pair. The "Trust me Bro" UX of fully autonomous agents is a trap that creates a new Doom Spiral of endless review. The real velocity comes from the "Editor" mode workflow: the human is the architect and navigator, holding the context, while the AI is the brilliant but naive junior partner handling syntax and boilerplate. It's still pairing, just with a new kind of partner.
- Trunk-Based Development. Avoid long-lived feature branches. The merge conflicts alone are a symptom of the Doom Spiral. Use short-lived branches or direct-to-main development combined with feature flagging.
2. Choke Your Legacy Code to Death
This philosophy of small, incremental change has a name when applied to legacy systems: The Strangler Fig Pattern. It's the most effective, and frankly most satisfying, way to deal with the monolithic monsters that inevitably grow inside any successful company.
You don't rewrite a legacy system. That's a fantasy sold by consultants and conference speakers. A full rewrite is a multi-year, multi-million dollar death march that will probably fail. Instead, you choke it out.
Like the tropical vine it's named after, you grow the new system around the old one. You identify a single piece of functionality, build a new service for it, and then use a proxy or router to divert a small fraction of live traffic to your new code. The old code and the new code run in parallel. You compare the outputs, the performance, the error rates. You prove, with real production data, that your new creation is superior.
This is self-testing in the only environment that matters: production. Once the new code is proven, you divert all traffic and turn off the old piece. You repeat this, function by function, until the old monolith is nothing but a hollowed-out husk, and you can delete it without ceremony.
This is how we evolved the Gopuff stack. We didn't stop the world to rewrite "Mixcart" into "Novus". We strangled it, piece by piece, while still shipping features at a ridiculous pace. It’s not about a big bang release; it's about a thousand tiny victories that, over time, result in a complete transformation. It trades the high risk of a total rewrite for the manageable risk of small, reversible changes.
3. Build a Culture of Distributed Trust
The fundamental principle that allows a startup to move at speed is federated trust. And sprints are a declaration of mistrust. They are a tool for managers to control engineers, to package work into predictable, chartable units.
This principle doesn't change with AI; it becomes sharper. You are not trusting a black-box AI agent to ship to production. You are trusting the human-AI pair. The engineer, augmented by this powerful new tool, is still the one you trust. They are accountable for the code, whether they typed it with their fingers or prompted it into existence. The trust is in the human's judgment, amplified by the tool.
My instruction to teams in the hyper-growth phase at Gopuff was blunt:
"Try and break it in the morning. You will not be blamed for breaking Production. We trust you to roll things back. This is a choice I have made that allows us to have increased velocity, and the risks have been clearly communicated to leadership."
This culture is supported by high-context collaboration and rapid deployment systems—not endless meetings or staging gates. The energy spent waiting on a Jenkins job or coordinating a two-week sprint release should be reinvested into developing resilient infrastructure that enables instant rollback and deployment.
Skip the dependency. Embrace the fluidity. Only then can you find your true velocity.
Process is a Weapon, Use it Wisely
The choice is simple. You can build a system of processes, ceremonies, and gates—a bureaucracy designed to protect you from incompetence. The sprint is the cornerstone of this system. It will feel safe. It will generate charts and reports. And it will slowly, inexorably, strangle your company's ability to ship. It is a system built on a foundation of mistrust.
Or, you can build a system of people. A culture of federated trust where engineers are empowered to move fast and fix their own messes. A system where velocity is a deliberate cultural and architectural choice, not an accidental outcome. This system is faster, more resilient, and infinitely more satisfying. In the age of AI, where the speed of creation is accelerating, this is the only system that will win. The Doom Spiral is a choice. Choose not to enter it.
The Goal: Build Small Things
Imagine a world where the words "merge conflict" are a forgotten relic of a bygone era, a curse word from a dead language. A world where developers never spend hours untangling the Gordian knot of a long-lived feature branch. This isn't a fantasy. It's the natural, inevitable outcome of a system built on a single, ruthless principle: build small things.
When your engineers are shipping tiny, atomic units of work every single day, the very concept of a merge conflict becomes absurd. You can't have a conflict when you're constantly integrating. This requires a different way of thinking. It requires writing bulletproof code, not because of some corporate mandate, but because the units are so small and well-defined that they are simple to reason about and nearly impossible to break in catastrophic ways.
This is the alternative to the Doom Spiral. You don't escape it with more process, more ceremonies, or more managers. You escape it by making the process irrelevant. You ship constantly. You integrate constantly. And you build a system so fluid and resilient that the bureaucratic rituals of "Agile" look as foolish and outdated as they actually are. This is the foundation of a truly agile infrastructure. When a problem occurs, it's trivial to roll back a single, tiny change. You have the levers to fix things instantly. Instead of investing in the theater of sprint planning, you invest in a resilient deployment system that makes shipping code—and fixing it—fast, safe, and boring. You escape the giant, terrifying releases trapped in a sprint-first architecture by making releases so small and frequent they become non-events.
