Agile vs waterfall: which fits your website budget

Waterfall is a way of running a project in fixed stages, one after another: requirements, design, build, testing, launch. Agile is a way of building in short cycles, where you see working pages every few weeks and decide what comes next. Both can give you a good website. They just split the risk very differently.

We wrote this for the owner who's paying, not the team running the work. We read the 1970 paper that's usually blamed for waterfall, the 2001 Agile Manifesto and the US government's own buying guides. Then we priced one made-up website both ways to show what a change of mind costs.

Waterfall fixes the scope, agile fixes the time box

That split, scope against time, drives every other difference. In waterfall you sign off on a full spec, then get a price and a date. In agile you agree on a budget and a sprint length, and the team builds the most valuable features first. The GAO's Agile Assessment Guide describes agile as software that's developed incrementally and "continuously evaluated for functionality, quality, and customer satisfaction."

Neither column is cheaper by default.

The same hours of work cost the same either way. What changes is who pays when the plan turns out wrong. In our experience, almost every website plan shifts a little once the owner sees real pages on a real phone, so that question decides more than any row in the table.

Royce never called it waterfall, and he warned against it

That fixed-stage model is usually traced to one conference paper by Winston W. Royce. So we read it. "Managing the Development of Large Software Systems" ran in the IEEE WESCON proceedings in August 1970. Its second page draws the familiar staircase: system requirements, software requirements, analysis, program design, coding, testing and operations.

Right under that drawing, Royce wrote that this single-pass version "is risky and invites failure" and then explained why. His reason was testing. Timing and storage problems only show up at the very end, when "invariably a major redesign is required" and the work goes back to the start. He put the price of that at "up to a 100-percent overrun in schedule and/or costs" for the project caught out.

Then we searched the paper's full text for the word waterfall, and it isn't there once.

Royce didn't throw the stages out. He added five fixes, including "do it twice" (build a pilot version first) and "involve the customer" at set points before delivery.

Those two ideas sound a lot like agile, 31 years early.

Agile got its name in February 2001, when 17 people met at a ski lodge in Snowbird, Utah and wrote a one-page manifesto. Its four values put individuals and interactions over processes and tools, working software over documentation, customer collaboration over contract negotiation, and responding to change over following a plan. The authors add that the items on the right still have value.

A few of the 12 principles behind it matter most when you're the one paying. One tells teams to welcome "changing requirements, even late in development." Another asks for working software every "couple of weeks to a couple of months" with a preference for the shorter end. And working software, not a status report, is "the primary measure of progress" in the authors' own words.

If you'd like the stage-by-stage view of a real build, our walk-through of the website development process covers each sign-off.

A fixed quote moves the risk to your vendor, and you pay for that

So which model costs less? Neither, on paper. The real difference is who carries the risk of a wrong estimate, and risk always gets priced in somewhere.

The federal government's buying rules define the two classic models clearly. A firm-fixed-price contract "places upon the contractor maximum risk and full responsibility for all costs and resulting profit or loss." That's waterfall's natural partner. A vendor taking on that risk adds a buffer to the quote, and you pay for that buffer whether or not anything goes wrong during the build. That's fair to them. It's just rarely shown on the invoice.

The opposite is time and materials, where you pay for hours at set rates. The FAR allows it only when costs can't be estimated "with any reasonable degree of confidence" at the start. It also warns that this model gives the contractor no positive profit incentive for cost control. Hourly agile with no cap has exactly the same weakness.

There's a middle option most owners never hear about.

The federal government's TechFAR Hub says agile contracts can be fixed-price, with line items structured by iterations (sprint cycles). You pay a set price per sprint, and extra sprints can be written as optional line items you buy only if you need them.

Rates themselves depend on who you hire. Hourly ranges, and what pushes them up, are in our full stack developer hiring guide.

Change requests are where waterfall gets expensive

You feel that buffer most on the day you change your mind. In waterfall, a change after sign-off is a change order: the vendor reprices it, and the date moves. In agile, the new idea goes into the backlog, and you decide what it replaces.

Example: Tidewater Kayak Rentals is a made-up kayak rental shop in Annapolis, Maryland. It wants a 12-page site with online booking. To keep the math simple, we price every hour at $100. That's an assumption for this example, not a quote or an October 2026 market rate.

Waterfall version: the agency scopes 240 hours, so the fixed quote is $24,000. Halfway through the build, the owner sees a competitor selling gift cards online and wants them too. The agency writes a change order for 30 more hours, or $3,000 at the assumed $100 an hour, and pushes launch back two weeks. The new total is $27,000.

Agile version: six two-week sprints of 40 hours each, the same 240 hours and the same $24,000 cap at the assumed $100 an hour. Gift cards go into the backlog. The owner ranks them above the photo gallery and the blog setup, which together were also about 30 hours. Those two slide to a later sprint, and neither launch day nor the budget moves.

Same work, same rate, two different bills.

Agile didn't make gift cards free.

It made the owner choose, which is the real trade: you keep the budget and give something else up for now. And if Royce's warning comes true on a waterfall build, his ceiling of a 100-percent overrun would mean up to $24,000 more on this example, at the same assumed rate.

Changes are most likely where nobody can see the work yet. If your site needs payments, booking or a CRM, read our guide to third-party integrations before you sign a fixed scope.

How much of your time does an agile website project need?

Reordering the list comes with homework. Agile only works if someone on your side makes the calls every sprint, and that person is usually you.

The 2020 Scrum Guide calls this role the Product Owner and says it's one person, not a committee. The Product Owner orders the backlog and decides what's built next. At the end of each sprint there's a review where the team shows finished work. For a one-month sprint the guide caps that review at four hours, and shorter sprints get shorter reviews.

Skip those reviews and you've bought a waterfall project with extra meetings, because nobody on your side is steering and the team will keep building whatever the backlog said three sprints ago. Show up, click through every page on your own phone, and say what's wrong while it's still cheap to fix. Put each review build through the free speed test on our site. It takes a minute and catches slow pages before they pile up.

Waterfall asks for about the same time, just bunched up: days on the spec at the start, days of testing at the end, quiet weeks between. Hiring a designer for that up-front work? Read how to hire a web designer before you sign anything.

Pick the model that matches the hours you'll really have.

Scrum and Kanban are ways to do agile, not rivals to it

Those sprints and reviews come from Scrum, the best-known way to run agile. The 2020 Scrum Guide calls Scrum "a lightweight framework" for complex problems. Its sprints are fixed-length events "of one month or less," and a Scrum team is "typically 10 or fewer people."

Kanban is looser. Work moves across a board from to-do to done with no fixed sprint. That suits ongoing updates, small fixes and support work after launch far better than it suits a brand-new build with a launch date.

So "agile vs scrum" isn't really a contest. If an agency says it works in two-week Scrum sprints, it's offering you agile.

A hybrid is what most small projects really need

But you don't have to pick a pure model. Few owners do. Most small-business websites do best with a fixed-price start and an agile build.

Here's how that usually runs. You pay a fixed price for discovery: goals, page list, designs for the key pages and a written backlog. Then the build runs in sprints under a budget cap. TechFAR describes the same split for federal buyers: firm pricing where the work is clear, and time-based pricing where considerable uncertainty remains.

The US Digital Services Playbook sets a pace worth copying. It tells agencies to ship a working first version no longer than three months from the start, then release improvements several times a month. A booking site for a small shop should fit well inside that.

The reason is risk, not fashion. The GAO says agile can reduce the risks of funding a program that fails or produces outdated technology. A small business can't absorb a failed build any better than an agency can.

Your platform changes the math too. On a hosted store builder, small changes stay cheap in either model; our WordPress vs Shopify comparison helps if you're choosing for a store.

Choose waterfall if your site fits on one page of notes

That's the test we'd use. If you can write every page, feature and integration on one sheet today, and it won't change, a waterfall quote is simple and fair.

Choose waterfall if the site is small and settled: a 5- to 10-page brochure site, a template you've already picked, or a grant amount you can't go over. Choose agile if you're building an app, a customer portal, booking, logins, or anything you expect to change once real customers use it. And choose a hybrid if you're in between, which is where most owners we talk to land.

Our take: a plain brochure site is fine on a fixed price with milestones. Anything with booking, logins or features you'll only discover later is safer with a fixed budget and a scope that can move. A fixed price on a fuzzy scope only looks safe.

It's the version where every surprise turns into a change order.

Not sure you need custom work at all? Compare no-code and custom development first, because a site builder can make the method question moot.

Want a second opinion on a quote you already have? Send your page list through our free quote form and we'll tell you which model fits. DigitalTreed builds websites for a living, so weigh our answer knowing that.

Put these lines in the contract either way

Whichever model you pick, the contract decides what happens when plans change. The Digital Services Playbook's budget and contract checklist was written for federal agencies, but most of it fits a small business website just as well. Ask for these six lines; the second, fourth and sixth come straight from that list:

• A written change process: who can ask, how a change is priced and how fast you get an answer.
• Frequent deliverables you can click through, not one big delivery at the end.
• Your right to reorder the backlog between sprints, if the build is agile.
• A warranty period for bugs found after launch, fixed at no extra cost.
• Ownership of the code, content, domain and accounts in your name.
• A handover plan, in case you switch vendors later.

New features you add along the way don't have to break the deal. TechFAR's note on contract changes says a change stays within scope if bidders "would have reasonably anticipated" it, which is why a contract that says the backlog will change protects both sides.

Before the final payment, run the live site through our broken link checker and submit every form yourself.

A launch with dead links isn't finished, whatever the contract's dates say.

We've explained how these pricing models work in plain words; that isn't legal advice. If the contract is bigger than an amount you'd shrug off losing, ask a business attorney in your state to read it before you sign.

And if you'd like us to build it, start with our web development service. That's our own paid service, so compare it with the other quotes on your desk.

How we made this guide: we read Winston Royce's 1970 paper in a public University of Washington copy and searched its full text. Our team then checked each quote from the Agile Manifesto, the 2020 Scrum Guide, the Digital Services Playbook, TechFAR Hub, the GAO guide and the FAR against its own page. The last check ran October 24, 2026. Tidewater Kayak Rentals and its numbers are made up to show the math. Every quote links to the page it came from. Before this goes live, Eram N. reads it and signs off on every change.

First published August 2020. Rewritten October 24, 2026: now a client's comparison of agile and waterfall, with pricing models, a change-request example, Royce's own words and a contract checklist. The copied definitions, the pasted video text and the unsourced Kanban figure are gone.

Sources

• Manifesto for Agile Software Development (2001)
• Principles behind the Agile Manifesto
• History: The Agile Manifesto (Jim Highsmith)
• The 2020 Scrum Guide, Ken Schwaber and Jeff Sutherland (November 2020)
• Winston W. Royce, Managing the Development of Large Software Systems, IEEE WESCON (August 1970)
• US Digital Services Playbook, Play 4 and Play 5
• GAO-24-105506, GAO Agile Assessment Guide (November 28, 2023; reissued December 15, 2023)
• FAR 16.202-1, Firm-fixed-price contracts
• FAR 16.601, Time-and-materials contracts
• TechFAR Hub: Contract design
• TechFAR Hub: Contract modifications for agile and digital services