Agile vs waterfall is a choice between planning everything first and then building it in one pass (waterfall), or building in short cycles and adjusting the plan as you learn (agile). For most app and website projects the honest answer sits between the two: a fixed discovery and design phase, then short build cycles with a clear budget. This guide explains both methods in plain words, compares them side by side, shows which fits websites, apps and brand work, and ends with the contracts that suit each and a checklist for choosing.
What are agile and waterfall, in plain words?
Before comparing them, it helps to strip both words of their jargon. Neither is a religion. Each is a way of deciding when you commit to what you are building, and how expensive it is to change your mind later.
Waterfall: decide, then build
Waterfall runs a project as a sequence of stages. Requirements are gathered and signed off, then design, then build, then testing, then launch. Each stage starts when the one before it is finished, and going back costs time and money.
Its strength is predictability. You know the scope, the price and the date before the first line of code is written. Its weakness is that it assumes you know everything at the start. When a real user meets the product for the first time, near the end, it is late to learn that a key screen does not work for them.
Agile: build, learn, adjust
Agile breaks the work into short cycles, usually one or two weeks, often called sprints. Each cycle ends with something working that you can see and test. The list of what to build next (the backlog) is re-ordered after every cycle, based on what was learned.
Its strength is adaptability. Mistakes surface early, when they are cheap, and you can stop at any point with something usable. Its weakness is that the final scope and cost are not fixed at the start, which makes some buyers nervous and makes a weak client-side owner a real risk: agile needs someone on your side who makes decisions every week.
Agile vs waterfall side by side
The table below sets out the practical differences a buyer will feel, not the theory.
| Waterfall | Agile | |
|---|---|---|
| Scope | Fixed at the start | Evolves cycle by cycle |
| Budget | Fixed price for a fixed scope | Fixed per cycle; total follows the scope |
| When you see working work | Near the end | Every one to two weeks |
| Cost of a change | High, through change requests | Low, absorbed into the next cycle |
| Your time needed | Heavy at the start and at sign-off | Steady, every week |
| Documentation | Detailed, written up front | Lighter, kept current as you go |
| Best when | Requirements are clear and stable | Requirements will change as you learn |
| Main risk | Building the wrong thing well | Scope and budget drifting |
Notice that neither column is “better”. Waterfall trades flexibility for certainty; agile trades certainty for flexibility. The right choice depends on how much you already know.
Which method fits websites, apps and brand work?
The type of project does more to decide the method than any preference of the agency. Here is how the three we work on most often usually fall.
Websites
A marketing or company website usually has a well-understood shape: a set of pages, a content management system, forms, search visibility. Much of it can be planned up front, which suits a waterfall-like structure for discovery, sitemap and design.
The build is where agility helps. Content arrives late, a page needs a new section, the client sees the home page in a browser and wants the hero to work differently. Building in short cycles on a staging site lets those changes land without a formal change request for each one. If you are budgeting, our guide on how much a website costs breaks down where the money goes in each stage of website development.
Apps
Apps, whether a mobile app or a web application with accounts, data and business logic, are where pure waterfall fails most often. Users behave in ways no specification predicts, platforms change their rules, and the most valuable feature is often one nobody wrote down at the start.
For an app, agile is close to the default. A first usable version (the minimum viable product) goes to real users as early as possible, and the next cycles are steered by what they do. Waterfall still has a place for the fixed parts: the data model, security requirements, integrations with existing systems and anything a regulator will read.
Brand work
Brand identity is a different animal. It moves through strategy, concept and craft, and each step depends on the decision before it. You cannot sensibly “sprint” a logo: an identity is chosen as a whole, from a small number of considered routes.
So brand work tends to follow a staged, waterfall-like sequence with review points, but with room to go back one step when a concept does not hold. When we built the identity for Nothing To Eat, the mark and its construction were settled first, and the website and its screens came after, built on top of decisions already made. If you are thinking about where identity ends and perception begins, our piece on brand image vs brand identity goes further.
Hybrid approaches that work
Most real projects are hybrids, whether or not anyone calls them that. The useful question is which parts are fixed and which are flexible. Three patterns come up again and again.
Fixed discovery, then sprints
This is the pattern we recommend most. The first phase is a fixed-scope, fixed-price discovery: goals, users, content, technical choices, a sitemap or feature map, and the key screens designed. You know exactly what it costs and what you will get.
Then the build runs in sprints against a prioritised backlog, with a budget per sprint and an estimate for the whole. You keep the certainty where it matters (the direction and the design) and the flexibility where it pays (the build and the details).
Waterfall with agile inside
Some organisations need a fixed contract and a fixed launch date: a public body, a launch tied to an event, a regulated product. Here the outer shell is waterfall, with a signed scope and milestones, but each milestone is built in short internal cycles with demos. The client sees working work every couple of weeks without the contract changing shape.
Agile with a fixed core
For an app, a common pattern is to fix the parts that are expensive to change (architecture, data model, security, the design system) and keep everything above them agile. Features move up and down the backlog freely, because the foundations do not move with them.
Which contracts fit each method?
The method you choose has to match the contract you sign. A mismatch, such as an agile process inside a rigid fixed-price contract, is the most common source of disputes we see.
Fixed price
A fixed price suits waterfall and fixed-scope phases such as discovery or brand identity. The agency carries the risk of the estimate, so the scope must be written down precisely: pages, features, rounds of revision, what is included and what is not.
Anything outside that written scope becomes a change request: a short document describing the change, its cost and its effect on the date, signed before the work starts. Change requests are not a trick. They are what keeps a fixed price fair to both sides.
Time and materials
Time and materials suits agile. You pay for the time actually spent, usually by the sprint or by the month, against an agreed rate. The scope can move freely, because the price follows the work.
The protection for you is visibility, not a fixed total: a backlog you can read, a demo at the end of every cycle, a running total against the estimate, and the right to stop after any sprint with everything built so far. A cap per month or per phase is a reasonable thing to ask for.
Fixed price per sprint
A middle way is a fixed price for each sprint, with a fixed team and a fixed length, and a flexible list of what goes into it. You know what each fortnight costs; the agency knows what it is committing to; the content of each sprint is agreed at its start.
If you are weighing up who to hire for the work as well as how to contract them, our comparison of a new agency vs an established agency covers what to ask both.
How does AI change the trade-off?
Part of the old argument for waterfall was cost: changing direction meant redoing work by hand. That is less true than it was. At Odduel, AI carries much of the repetitive production (design-system components, front-end code, first drafts, test cases, first-pass translations), so a cycle produces more working work and a change of direction costs less to absorb.
What does not get cheaper is judgement. Strategy, concept, art direction, the voice of the brand and the final review stay human work, and that is where the budget goes. In our experience this tips more projects towards short cycles: when building is fast, it is better to see real screens early than to perfect a specification no user has tested. It is how we run application development and UX and UI design projects from Barcelona and São Paulo.
How do you choose? A checklist
Answer these questions honestly. The more answers fall on the left, the more waterfall suits you; the more on the right, the more agile does.
- Requirements. Can you write down everything the product must do today (waterfall), or will you learn most of it from users (agile)?
- Budget. Do you need one fixed number signed before work starts (waterfall), or can you work with a budget per month and a running total (agile)?
- Deadline. Is the date fixed by something outside your control (waterfall shell), or is it a target you can trade against scope (agile)?
- Your time. Can someone on your side review work and make decisions every week (agile), or only at a few milestones (waterfall)?
- Users. Can you put an early version in front of real users (agile), or does nothing go out until everything is finished (waterfall)?
- Compliance. Does a regulator, a procurement rule or a board need a full specification up front (waterfall, at least for the outer shell)?
- Type of work. Is it brand identity (staged), a marketing website (hybrid) or an app (agile with a fixed core)?
If your answers are mixed, that is normal. Choose a hybrid and decide, part by part, what is fixed and what is free.
Questions people ask
Is agile always more expensive than waterfall?
No. Agile can look more expensive because the total is not fixed at the start, but waterfall projects often end up paying for change requests and rework after launch. Agile spends the budget on what users actually need, and you can stop once the product is good enough. The real cost difference comes from how well each is managed.
Can a fixed-price contract be agile?
Partly. A fixed price per phase or per sprint works well with agile, as long as the scope inside each one is agreed at its start. What fails is a single fixed price for a fixed list of features combined with a promise of flexibility: one of the two gives way, usually in a dispute.
Which method is better for a website redesign?
Usually a hybrid. Discovery, the sitemap and the key page designs benefit from being fixed and signed off; the build, content entry and refinements benefit from short cycles on a staging site. The existing site gives you a lot of knowledge up front, which makes the fixed part easier to scope.
How long is a sprint in an app project?
Most teams use one or two weeks. One week keeps feedback tight but leaves little room for larger features; two weeks is the common balance. What matters more than the length is that every sprint ends with something working that you can see and try.
What do I need to provide in an agile project?
A product owner on your side: one person who knows the business, can set priorities and is available every week to review work and answer questions. Without that person, agile slows down, because the team waits for decisions that nobody is empowered to make.
If you have an app or website in mind and are unsure how to structure it, start with a short fixed discovery: it gives you a price for the build, a design to react to and the information to choose the method with confidence. See how we approach application development, or talk to us about your project.
