Most business owners interviewing software developers spend their time negotiating price and timeline. They rarely ask one question that matters just as much: how will this project actually run, week to week, once the contract is signed.
That question is really about methodology. Agile and waterfall are the two dominant ways of running a software project, and they produce very different experiences for the client, not just for the development team. Pick the wrong one for your situation and you will feel it in delays, budget surprises, and a final product that technically matches the brief but misses what your business actually needed by the time it launched.
Why this choice quietly costs businesses more than they expect
Consider a mid-sized logistics business in Johannesburg that signs a fixed-price, fixed-scope contract for a new dispatch system. Three months into a six-month build, a new client requirement comes in: real-time GPS tracking that was never part of the original brief. Under a strict waterfall contract, this is treated as a change request. The developer is within their rights to quote it separately, push out the timeline, and reopen the budget conversation. The business owner is not wrong to be frustrated, but they signed up for exactly this risk profile without realising it.
Flip the scenario. A startup founder hires a development team on an open-ended agile retainer with no fixed scope and no fixed end date. Every sprint brings new ideas, every demo sparks new requests, and six months later the founder has spent more than double the original estimate on a product that still is not live, because nothing was ever locked down long enough to ship.
Neither outcome is a methodology failure on its own. They are mismatch failures: the wrong approach was applied to the wrong kind of project. The hidden costs of choosing the wrong software path compound quietly, and by the time they are visible, the business has usually already paid for them in delays, renegotiated invoices, or a product that does not fit.
How methodology shapes your contract and your invoices
The methodology you choose is not just a working style. It usually determines how you get billed, and most business owners only discover this after the contract is already signed.
Waterfall projects are almost always quoted as fixed-price, fixed-scope contracts. You get a single number for the entire build, tied to a specific, documented set of requirements. This is attractive because it makes budgeting simple, but the certainty only holds if the brief does not change. The moment requirements shift, you are no longer inside the original quote, you are negotiating a change order, and change orders are where fixed-price contracts quietly become expensive.
Agile projects are usually billed as time-and-materials, either through a monthly retainer or a per-sprint rate. You pay for the team's time over a defined period rather than for a fixed final deliverable. This is honest about how the work actually happens, but it means the final cost is genuinely open-ended unless someone is actively managing scope sprint by sprint. A business that wants a fixed number to take to a board or a bank should think carefully before agreeing to open-ended time-and-materials billing.
Custom software builds in South Africa vary widely in cost depending on complexity, but as a rough anchor, a focused custom build often starts from R50,000 for a narrowly scoped tool and climbs from there as integrations, user roles, and data complexity increase. Whichever billing model you agree to, ask explicitly how scope changes get priced before you sign, not after the first one arrives.
What waterfall actually means for your project
Waterfall is a linear approach. Requirements get defined and signed off first. Design happens next, then development, then testing, then launch. Each phase finishes before the next one starts, and once a phase is signed off, going back is expensive.
This sounds rigid because it is, and that rigidity is the entire point. Waterfall works well when the requirements are genuinely stable: a system replacing a known manual process, a build with a hard regulatory deadline, or a project where the budget has to be approved once and cannot move. Government tenders and compliance-driven systems are classic waterfall candidates, because the client needs cost certainty more than they need flexibility.
The risk shows up when requirements are not actually stable but get treated as if they are. A detailed, accurate brief at the start is what makes waterfall safe. A clear, well-documented software brief is the difference between a smooth waterfall build and one where every changed mind becomes a billable change order.
What agile actually means for your project
Agile breaks the project into short cycles, usually called sprints, typically one to three weeks long. At the end of each sprint, the client sees working software, not a mockup or a status report. Priorities can shift between sprints based on what was learned from the last one.
This is the right approach when the product itself is still being discovered. A startup testing whether an idea has demand, a business building an internal tool where the real requirements only become clear once people start using an early version, or any project where speed to a usable first version matters more than locking in every detail upfront. Agile trades certainty for adaptability, and for the right kind of project, that trade is exactly what de-risks the build.
The trap is treating agile as a substitute for planning rather than a way of managing it. Without a clear product owner making real prioritisation calls, sprints drift, scope grows quietly, and a project with no fixed end date can run indefinitely. Agile needs more client involvement, not less, because someone has to keep saying no to the requests that do not fit the current sprint.
The questions that should actually drive your decision
The methodology debate gets treated as a philosophical one. In practice, it is answered by a handful of concrete factors specific to your project.
- How well-defined is the brief today? If you can describe the finished product in detail right now, waterfall is viable. If you are still figuring out what the product should do, agile fits better.
- Is the budget fixed and final, or does it have room to flex? Waterfall suits a hard budget ceiling. Agile suits a budget that can grow if the product proves itself.
- Does a regulator, funder, or board need a fixed delivery date? Compliance and grant-funded projects usually need waterfall's predictability.
- How much capacity does your team have to be involved weekly? Agile only works if someone on your side can review progress and make decisions every sprint. If nobody has that time, agile becomes directionless.
- Is this a known process being digitised, or a new idea being tested? Digitising a known process favours waterfall. Testing a new idea favours agile.
Most South African SMEs answer these questions with a mix of both, which is exactly why the purist version of this debate misses the point.
Why most businesses need a hybrid, not a purist's answer
In practice, almost every project we build at CodeLab One uses a blend. The discovery phase and core architecture get treated with waterfall discipline: requirements are documented, the brief is locked down, and the client signs off on scope before serious development starts. Once that foundation is in place, the actual build runs in short, visible cycles, with the client seeing working software every one to two weeks rather than waiting for a single big reveal at the end.
This hybrid model gives clients the budget certainty of waterfall during planning and the flexibility of agile during execution. It is particularly suited to custom software builds and custom web application projects, where the core requirements are usually clear but the finer details of the user experience benefit from being refined against working software rather than static documents.
Industry research on this is consistent. Long-running studies on software project outcomes, including the Standish Group's CHAOS research, have repeatedly found that projects run with iterative, incremental delivery succeed at meaningfully higher rates than those run as a single large waterfall release, largely because problems surface early enough to fix cheaply. At the same time, the Project Management Institute's own surveys of practitioners consistently show that the businesses with the best outcomes are not strict adherents to one methodology. They adapt the approach to the project, which is the hybrid model in practice rather than in name.
In practical terms, this looks like a two to four week discovery phase where requirements, user roles, and integrations get documented and signed off, followed by build cycles of one to two weeks where you log in and use the actual product as it grows, rather than reading about its progress. Scope can still flex inside each cycle, but the foundation underneath it does not move, which is what keeps both the budget and the timeline honest.
Questions to ask before you sign with any development partner
Whoever you choose to build with, the methodology conversation should happen before the contract is signed, not after the first delay.
- How will change requests be handled, and what triggers a new quote versus what is absorbed into the existing scope?
- How often will I see working software, not a status update or a slide deck?
- Who on my team needs to be involved weekly, and how much time should they budget for it?
- What happens if my requirements change significantly halfway through the build?
- Is the quote fixed for the full scope, or will it be re-quoted as the project evolves?
- What does a typical sprint or phase actually look like in practice, with a real example from a past project?
A development partner who cannot answer these clearly, or who insists their single methodology fits every project regardless of its nature, is a warning sign worth taking seriously.
Frequently asked questions
Is agile always faster than waterfall?
Not necessarily. Agile gets you a usable first version faster, but the total time to a fully finished product can run longer if scope keeps expanding sprint after sprint. Waterfall can be slower to first launch but more predictable about the final delivery date, provided the original brief was accurate.
Which approach costs less?
It depends on how stable your requirements are, not on the methodology itself. A well-briefed waterfall project and a well-managed agile project can land at similar costs. The expensive outcomes happen when the methodology does not match the project: a waterfall build with shifting requirements, or an agile build with no one managing scope.
Can a project switch from waterfall to agile partway through?
Yes, and it is more common than people expect, particularly once the core architecture is locked down and the remaining work is refinement and feature additions. A good development partner will flag when this shift makes sense rather than forcing one methodology for the entire project regardless of how it is evolving.
Do I need technical knowledge to manage an agile project?
No, but you do need to be available and willing to make decisions regularly. The technical execution sits with your development team. Your job is prioritisation: deciding what matters most for the next sprint and saying no to requests that do not fit it.
How do I know which approach a potential developer actually uses, beyond what they claim?
Ask for a specific example from a recent, similar project: how change requests were handled, how often the client saw working software, and what the final cost looked like versus the original quote. Real answers with real numbers tell you far more than a description of their "process."
The honest answer to agile versus waterfall is that the question itself is usually too narrow. The right approach is the one that matches how well-defined your project is today and how much flexibility your budget and timeline can absorb if that changes. If you want a clear, honest assessment of which approach fits your specific project, book a free consultation with CodeLab One and we will walk through it with you before any contract gets signed.
