Agile or Waterfall: Which One Fits Your Project?

Both names turn up in proposals, and both sound like an internal matter for the development team. For the person paying, the difference is simpler: how long it takes before you know whether the software actually fits the way you work.

Waterfall settles everything on paper first and shows you the result at the end. Agile fixes the scope of one short stage, hands you something you can open, then lets you change what comes next. Two things are worth judging in any proposal: how often you see working software, and how often you are allowed to stop.

What each approach actually asks of you

Waterfall wants every decision up front. You spend weeks with their team explaining your process, approve a thick document, then sign one number for the whole project. After that you wait. The meetings that follow tend to be progress reports expressed as percentages, and software you can open yourself arrives near the end.

Agile wants smaller decisions, more often. You say what matters most for the next few weeks, see it running, then decide again. Your own time goes in regularly, in small amounts. If it leaves you uneasy that nobody announces a total at the start, the staged fixed price further down this piece is the answer to that.

What changes between the two is how long a misunderstanding sits before it surfaces. Explain something badly to a waterfall team and the mistake can wait months to show up; explain it badly inside a two-week stage and it shows up in the next demo. The thinking behind agile, written for business owners rather than developers, is in our guide to agile and lean development.

Where waterfall still makes sense

This approach works well when the end result is already fixed and will not shift. A report whose format is set by a regulator belongs in that category. So does a process that has been stable for years and will not change in the next one, like a calculation whose rules are written down and rarely revised. The clearest case is replacing an old system, because the system running today is already the specification, odd behaviours included, so there is little left to discover halfway through.

A long document is also reassuring, and that is worth admitting. It looks like certainty, and to someone about to sign off a large expense, that feeling has value. The trouble starts when the document describes a process that is still moving.

Where it breaks for a growing business

Smaller companies usually commission custom software precisely because the process is not settled yet. Orders are logged in a spreadsheet that keeps gaining columns, or there is one step whose rules live only in one person's head and have never been written anywhere. That step has to come out of that head and onto paper eventually, and discovery is where it happens, because the written plan cannot be finished while one of the rules is still undocumented.

A process like that keeps moving. Your own team changes it a few times, so a specification written in month one describes a way of working that no longer exists by month five. A new supplier arrives with different payment terms, or an admin finds a shortcut that turns out to be better than the official route.

The expensive part is the order of events. If the first time you open the software is at the end, that is also the first time you can object. Open a preview link in week two and you notice that two of the fields on the new booking screen are never known at the time the booking is taken. Noticing that in week two costs one screen, while noticing it after the build is finished means unpicking everything that sits on top of it, plus an argument about who pays for the unpicking.

The two questions that decide it

Whatever the method is called, you can judge a proposal on two answers.

How often do you see software that actually runs? That means a link you can open on your own phone, not a progress report and not design screenshots. "Every week" and "at the end of phase two" produce very different projects, even though both can call themselves agile.

After which point can you stop without an argument? Stopping is always possible in a legal sense, but a stop point is only usable when its price and scope were agreed before that stage began. If the only stop point is at the end of the project, you really have one decision, and you made it when you signed.

The hybrid most SME projects actually need

Waterfall carries the fear of cost with no visible ceiling, and agile carries the fear of waiting too long to find out whether the money is going somewhere useful. Both are answered by breaking the project into stages, each with its own fixed price.

We run builds that way. Scope and price for every stage are agreed in writing before that stage begins, so you can stop after any stage without an argument, because the next one was never something you approved. The commitment is short, the way it is in agile, and the number is certain, the way it is in waterfall.

The first stage is discovery. It takes one to two weeks and produces a written plan with a fixed price, and that document is yours whether you continue or not, so you know in advance what it costs to measure the size of the work. During the build there is working software every week and a private preview link from week one, and what you flag in that weekly demo is what the next stage's scope gets agreed from.

The risk of being stranded mid-project is closed from the other side. The code, servers, domain and every account are in your name from day one, not at handover. Stop after stage two and what exists is already yours, accounts included, so whoever you choose next can pick it up without asking us for anything. The stage sequence is set out in our end to end approach from idea to launch, and how to choose what goes in the first stage is covered in our post on building a small first version.

What to ask a vendor before you sign

The method named on page one of a proposal tells you very little. The answers to these questions tell you almost everything:

• When do I first get a preview link I can open myself, and how often does what is behind it change?
• During the build, who am I talking to: the person writing the code, or someone relaying messages to the person writing the code?
• Whose name is on the server, the domain and the third-party accounts, and from when?
• If we decide to stop after stage two, what do I hold and what is still owed?
• What gets written down alongside the code for whoever maintains it after you?

With us, you talk directly to the engineers building it. Nothing is subcontracted and nobody is swapped out after signing, so the people you meet today are the ones on it in six months. The same questions are worth putting to any studio, and if the answers circle rather than land, you have the information you came for. The wider set of things to weigh before commissioning a build is in our guide to commissioning custom software.

Bring the project, we'll work out its shape

Rather than picking a method by its name, just describe the process. The first call is free and there is no deck. We look at how settled your current way of working is, then decide whether the project suits short stages or is predictable enough to run in one pass. If what you need already exists as a tool you can buy, we will say so.

If the work goes ahead, discovery gives you a written plan and a fixed price within one to two weeks, and that document is yours whatever you decide afterwards. Use the contact form, which opens WhatsApp, or email hello@arktik.id.