Agile vs Waterfall for Custom Software Development: What Actually Works

The Debate That Isn't Really a Debate Anymore

Ask any engineering team and they'll tell you agile won. In practice, almost every custom software project we run is a hybrid: waterfall-shaped commitments — a fixed scope, a fixed price, a delivery date — wrapped around an agile execution process of two-week sprints, continuous feedback, and iterative builds. Pure waterfall, where you write a lengthy spec, disappear for six months, and deliver, fails because software requirements change the moment users see a working product. Pure agile, with no fixed scope and no fixed budget, fails because most clients spending their own money need to know what they're getting and when.

This isn't a theoretical stance we picked because it sounds balanced — it's what we've converged on after running both pure models and watching them fail in predictable ways. Pure waterfall projects where we locked a lengthy spec and disappeared for months routinely delivered software the client no longer wanted by the time it shipped, because the market or the founder's understanding of the problem had moved on. Pure agile projects with no fixed commitment left clients unable to plan their own runway, which for a funded startup is its own kind of risk.

Where Waterfall Still Wins

Waterfall's strength is predictability, and there are real situations where predictability matters more than flexibility: regulated industries with fixed compliance requirements, fixed-price contracts where the client needs budget certainty, or projects with hard external deadlines like a trade show launch or a contractual go-live date. In those cases we still do upfront discovery and lock a detailed scope before writing code, because the cost of scope drift is higher than the cost of losing some flexibility.

This is also where regulatory audits live. A healthcare or fintech client who needs a paper trail showing exactly what was specified, reviewed, and approved before a single line of code was written benefits from waterfall's rigidity in a way an early-stage consumer app never will. We don't apply agile dogma to a project just because it's fashionable — we match the process to what the client is actually optimizing for.

Where Agile Wins

Most consumer and B2B SaaS products don't have a fixed answer up front — the founder has a hypothesis, not a spec. Agile delivery, with working software shipped every sprint, lets the client see and use real functionality early enough to catch wrong assumptions before they're expensive. We've had clients change their entire onboarding flow after seeing a sprint-two demo, which would have been a costly change order under waterfall and was just sprint three under agile.

The mechanism that makes this work is cheap iteration. A wrong assumption caught in a two-week sprint costs a conversation and a re-prioritized backlog. The same wrong assumption caught after months of silent development costs a rebuild, a blown deadline, and usually a much harder conversation about budget. Agile doesn't eliminate the risk of building the wrong thing — nothing does — it just makes the cost of discovering that risk early instead of late.

The Hybrid We Actually Run

Our default model locks scope and budget at a milestone level while executing each milestone in two-week sprints with a working demo at the end of each one. The client always knows the total cost and timeline, and they still get to redirect priorities within a milestone based on what they learn. This isn't a compromise for its own sake — it's the only model that satisfies both needing to know what you're paying and needing the software to actually be right.

The Real Failure Mode

The projects that go sideways aren't the ones that pick the wrong methodology — they're the ones that pick a methodology and then don't follow its discipline. Teams that claim to be agile but never demo working software, or teams that claim to be waterfall but keep re-negotiating scope mid-build without a change process, get the worst of both: no predictability and no flexibility.

We've seen this from both directions as an external vendor: clients who insist on agile because it sounds modern, then get uncomfortable the first time a sprint demo shows something that isn't finished yet, because they were expecting waterfall's illusion of completeness at every checkpoint. And clients who insist on waterfall for control, then quietly ask for feature changes every other week without acknowledging that they've turned it into agile without the structure that makes agile safe.

Methodology is a tool for managing risk, not a philosophy to be loyal to.

How to Choose, Practically

Ask three questions before picking a process. How well-defined is the problem? How much does the budget need to be fixed in advance? How much does the client, or your own team, need to see working software before committing further? A project with a clear spec, fixed budget, and low uncertainty leans waterfall. A project with high uncertainty and a founder who can iterate on feedback leans agile. Most real projects land somewhere in the middle, which is exactly why we don't pick one and force every client into it.

For the full picture of how we run engagements, see our delivery process.