Agile vs Waterfall: Which Fits Your Software Project?

Agile vs waterfall comes down to one question: when do you decide what gets built? Waterfall fixes everything up front and builds it in one long pass, while agile builds in short cycles and adjusts the plan as you learn. For most small software projects, the honest answer is a mix: a fixed budget and frame, with agile delivery inside it.

A note on bias: I start larger builds with a paid, fixed-price discovery phase, so I have a stake in this. That's why I've also spelled out when that approach is the wrong call.

The short answer

My rule of thumb: if you can describe the finished result precisely today, and that description will still be right in three months, waterfall can work. If you're unsure about either, build in short cycles. Most small projects land somewhere in between, which is where the hybrid further down comes in.

For the bigger picture of how a project runs from first idea to live software and beyond, see my guide to the software development process.

What the waterfall model actually is

Waterfall runs a project as a sequence of phases: requirements, design, build, test, release. Each phase has to be finished and signed off before the next one starts, so the work flows downhill one step at a time.

The model is usually traced back to a 1970 paper by Winston Royce. The irony is that Royce called the strict one-pass version risky, since testing only happens at the very end, and he never used the word waterfall at all. The Wikipedia article on the waterfall model covers the history well.

Waterfall gets bad press among developers, but it has real strengths:

• You know the price and the delivery date before you sign.
• Everyone has read and approved the same document, which leaves less room for arguments about what was agreed.
• It suits organizations where budgets are approved once a year and any change needs sign-off from above. Public bodies across the EU often buy software through tenders that expect a detailed specification up front.

The cost of that certainty is that every decision gets made when you know the least. You have to guess how people will use the software before anyone has tried it, and if you guess wrong, you find out when the budget is gone. If you do need a thorough spec, start with my software requirements specification template.

What agile development means in practice

Agile is an umbrella term for ways of working where you build in short cycles, show the result and adjust the plan based on what you learned. The term comes from the Manifesto for Agile Software Development, written in 2001, which puts working software ahead of extensive documentation and responding to change ahead of sticking to a plan.

Scrum is the best-known agile framework. The Scrum Guide sets sprints at one month or less and gives one person, the Product Owner, the final say over the order of the backlog (the prioritized list of work still to do). On a small project with a freelance developer, that person is usually you, whether or not anyone uses the title.

A typical cycle on a small project looks like this:

1. You and the developer pick the most important items from the top of the backlog.
2. The developer builds them to done, including tests.
3. You try the result yourself on a staging server (a private test copy of the app).
4. You reorder the backlog based on what you saw, and the next cycle starts.

Backlog items are often written as user stories: a sentence or two on what a user needs to do, and why. My guide on how to write user stories a developer can build from covers the format.

One misconception to clear up: agile doesn't mean there's no plan. It means the plan gets updated as you learn. A project with no goal, no budget and no prioritized backlog isn't agile. It's just unmanaged.

Fixed budget, flexible scope: the hybrid that suits small projects

Most people buying software want two things that sound incompatible: a fixed price and the freedom to change their mind. You can have both if you separate the frame from the contents.

The frame is fixed. Budget, deadline, the goal, and the handful of features the product can't launch without. That's the waterfall part, and it's agreed before any code is written.

The contents are flexible. Everything else lives in a prioritized backlog. The developer works from the top, you see progress every cycle, and when a new idea comes up, you swap it in for something of similar size. If time runs short, the bottom of the list gets cut, not quality or the deadline.

Put simply, you can't get more for the same price, but you can get something different. That beats waterfall's change requests, where every tweak turns into a negotiation, and it beats open-ended hourly billing, where you only learn the total at the end. I compare the two pricing models in more detail in fixed price vs hourly rate.

The frame is only as good as the information behind it. That's why I start larger builds with a paid, fixed-price discovery phase, where the goal, the core features and the technical direction get pinned down before anyone puts a price on the rest.

When each approach is the wrong choice

The hybrid isn't right for everything, and both pure models have their traps. These are the situations where they tend to cost you money.

When waterfall is a bad fit

• You're building something users haven't tried before. An MVP (the first, simplest version of a product) is an experiment, and you can't fully specify an experiment in advance.
• Your market or business moves faster than the project timeline.
• You find it hard to read a spec and picture the finished product. Plenty of people approve a document and get a surprise when they see the screens.
• Writing a complete spec would eat a large share of the budget meant for building.

When agile is a bad fit

• Your budget is locked and you need to know exactly what it buys. Pure agile on an hourly basis can't answer that.
• Nobody on your side has time to take part. Agile needs someone to review the work, answer questions and set priorities, usually a few hours a week. Without that, the developer is left guessing.
• The requirements really are fixed: an integration with a known API, a data export in a format set by a regulator, or a tender with a detailed specification. Short cycles mostly add meetings.

When the hybrid is a bad fit

• The job is small, say a few days of work. A discovery phase and a backlog are more process than the task deserves. Ask for a fixed quote on a short written brief instead.
• The must-have list alone costs more than your budget. No way of working fixes that. Trim that list or raise the budget before anyone writes code.

How to set up a fixed-frame agile project

The approach lives or dies by the agreement. Here's how I'd recommend setting it up:

1. Write the goal in one sentence. What will be different once the software is live? "Customers can book and pay online" is a goal. "A new platform" isn't.
2. Sort features into three piles: must have for launch, should have, and can wait. Be strict with the first pile, because that's what sets the price.
3. Put the frame in writing: budget, deadline, the must-have list, and how changes are handled. My rule of thumb is to keep 15-20% of the budget unallocated for things you only discover along the way.
4. Agree on a demo rhythm, weekly or every other week, where you try what's been built. If you're in different time zones, a recorded walkthrough plus a staging link works well between live calls.
5. Swap, don't add. A new idea goes in only if something of similar size comes out or moves to the next version.
6. Insist that every cycle ends with something that works and is tested, so you could stop the project without being left with half-finished code. That's one reason automated tests pay off even on small projects.

Next steps

Answer two questions honestly. How sure are you about what needs to be built? And how much time can you give the project along the way? If the answers are "very sure" and "almost none", a classic fixed price on a detailed spec is the right call. In almost every other case, I'd recommend a fixed frame with a prioritized backlog.

You can see how I price projects on my pricing page. If you already have a brief or a spec, send it along when you get in touch.

Frequently asked questions

Is Scrum the same as agile?+

No. Agile is a set of values and principles, while Scrum is one specific framework built on them, with defined roles, sprints and meetings. Kanban is another common approach, where work is pulled from a board one item at a time without fixed cycles. Small projects often use a light version: short cycles, a prioritized backlog and regular demos, without the full set of Scrum meetings.

How long should a sprint be on a small project?+

One to two weeks is a good default. The Scrum Guide allows up to a month, but long cycles mean you wait too long before you can see the work and change course. Very short cycles have the opposite problem: planning and demos take up too much of the time that should go into building.

Do I still need a requirements document for an agile project?+

Yes, just a shorter one. You still need the goal, the users, the core features and any hard constraints around integrations, security and data. What you can skip is a detailed description of every screen and rule. Those are cheaper to settle once you can see and click through the real thing.

Can agile work with a remote developer in another time zone?+

Yes, as long as demos and decisions don't depend on everyone being online at the same time. Written updates, a staging link and a short recorded walkthrough per cycle cover most of it, with a live call for bigger decisions. Within Europe and the UK, working hours overlap anyway, and the US East Coast morning overlaps with the Central European afternoon.

What happens if the budget runs out before everything is built?+

With a fixed frame and a prioritized backlog, you end up with working software that has the most important features. What's missing is the bottom of the list, and you can decide later whether that becomes a second phase, ongoing development or nothing at all. On a pure waterfall project, you can end up with something nearly finished that can't be used.