Waterfall
A sequential development model where each phase (requirements, design, build, test, deploy) finishes before the next begins. Solid for fixed, well-understood scope, poor for product discovery.
Waterfall runs a project as an ordered sequence of phases: gather all the requirements, then design the whole system, then build it, then test it, then deploy it. Each phase produces a signed-off document and finishes before the next one starts. The appeal is obvious: you know the plan, the cost, and the date up front, and everyone agrees to it before a line of code is written.
It still legitimately fits some work. When the scope is genuinely fixed and well understood, when a regulator requires up-front documentation and traceability, or when you are building hardware where you cannot cheaply iterate after the metal is cut, sequential phases are the honest model. Pretending such a project is “agile” just hides the plan instead of removing it.
The contracting angle is where Waterfall and Agile collide most concretely. A fixed-price Werkvertrag, under Austrian and German law, needs a defined deliverable to bind the vendor to, which pushes naturally toward a waterfall-shaped, fully-specified scope. Genuinely iterative work, where you expect the requirements to change as you learn, fits a Dienstvertrag or a retainer better. Founders get into trouble when they want the legal certainty of fixed-price and the flexibility of agile at the same time: those pull in opposite directions. The honest resolution is usually to do a fixed-price discovery to nail down enough scope to fix a price on, then run the build with whatever boundary permeability the remaining uncertainty actually warrants.
It fails badly for product discovery. The fatal assumption is that you can specify the right product up front, before any user has touched it. You almost never can. By the time the build phase ends, the requirements gathered months earlier are partly wrong, and Waterfall has no cheap way to find out until the testing phase, when changing anything is expensive. You get a product that matches the spec and misses the need.
The honest distinction from Agile: Waterfall front-loads all the decisions and bets that they are right. Agile (whether run as Scrum or a lighter flow) spreads decisions across the work and bets that early feedback will catch the wrong ones. Either way, both are just sequencing choices over the same underlying SDLC stages. For anything where you do not yet know exactly what to build, the bet favours Agile. For anything where the answer is genuinely known and fixed, Waterfall’s predictability is a feature, not a flaw.