Every software or website project follows a method, even when nobody names it. The method decides when the client sees work, when changes are cheap, and when they become expensive. Choosing it on purpose, at the start, avoids most of the arguments that come later. This guide compares the common methods in plain terms and shows how they fit a project split into milestones.
Waterfall: plan everything, then build
Waterfall runs in fixed phases: requirements, design, build, test, release. Each phase finishes before the next one starts, and the client mostly sees the result at the end.
- Works well when the requirements are clear and stable, such as a fixed integration with a documented system, a regulated process, or a rebuild of something that already exists.
- Watch out for late surprises. A misunderstanding in the requirements may only surface during testing, when it is costly to change.
Prototyping: show before you build
The team builds a quick, rough version, often clickable screens with no real code behind them, and puts it in front of the client and a few users. Their reactions shape the real build.
- Works well when the client struggles to describe what they want until they see it, or when the user interface is the risky part.
- Watch out for a prototype that looks finished. Agree in writing that it is a sketch, so nobody expects it to go live next week.
Agile and Scrum: short cycles of working results
Agile is a set of values written down in the Agile Manifesto in 2001: working results over long documents, collaboration with the customer, and responding to change. Scrum is the most widely used framework built on those values. Its official rules are in the Scrum Guide, last revised in 2020.
In Scrum, work happens in sprints of one month or less, often two weeks. Each sprint starts with planning, delivers a usable piece of the product, and ends with a review where the client sees it and adjusts the priorities, followed by a retrospective where the team improves how it works. A product owner keeps an ordered list of everything still to do, the backlog.
- Works well when the goal is clear but the details will change, which describes most new products.
- Watch out for a client who is not available. Scrum depends on fast feedback after every sprint. Without it, it becomes waterfall in short pieces.
Kanban: a steady flow
Kanban has no fixed cycles. Work items move across a board with columns such as To do, In progress, Review and Done. The team limits how many items can be in progress at once, which keeps work flowing and makes bottlenecks visible.
- Works well when requests arrive continuously, such as website maintenance, support or small improvements after launch.
- Watch out for work without an end date. Kanban needs clear priorities, or urgent small items crowd out important large ones.
Other names you will hear
- Extreme Programming (XP) is a set of engineering practices often used inside agile teams, such as pair programming, automated tests written first and small, frequent releases.
- The spiral model repeats plan, risk analysis, build and review in loops, and suits large projects where the main risk is technical.
- Rapid Application Development (RAD) leans on prototypes and quick iterations to get a working system out fast.
- Hybrid approaches are common in practice: plan the scope and budget up front like waterfall, then build in short agile cycles.
How to choose
| If your project is like this | Consider |
|---|---|
| Fixed, well-documented scopeLittle is expected to change | Waterfall, with a clear test phase. |
| Unclear look or flowThe client will know it when they see it | Prototyping first, then build. |
| A new product with a clear goalDetails will change along the way | Scrum or another agile approach. |
| Ongoing requests and upkeepNo natural end | Kanban. |
| A fixed budget and an evolving designThe most common case for small clients | A hybrid: agreed milestones, short cycles inside each one. |
How milestones on Internetivo map to these methods
On Internetivo, a client splits a project into milestones. Each milestone has its own deliverable and its own share of the price. When you deliver a milestone, the client can approve it, request a revision or open a dispute. If they do not answer, it is approved automatically seven days after delivery, with reminders on day 3 and day 6, unless a revision was requested or a dispute is open. You are paid for each approved milestone once the client's payment has been received, and you receive at least 85% of every milestone.
That structure fits each method in its own way:
- Waterfall: make each phase a milestone, for example requirements, design, build and launch. The approval of each phase is the sign-off waterfall needs.
- Scrum: make one sprint, or a group of two or three, a milestone. The milestone review is the client's sprint review, with a clear deliverable to look at.
- Prototyping: make the prototype the first milestone. Once it is approved, the build milestones rest on something the client has already seen.
- Kanban: group a period's worth of finished items, or one batch of requests, into a milestone, so each one has a clear end.
Whichever method you choose, write each milestone as an outcome the client can check, such as "booking form working on the preview address", rather than activity, such as "two weeks of development". Clear outcomes make reviews quick and approvals easy. For the payment side, read Getting paid on Internetivo.
Common questions
- Is agile always better than waterfall?
- No. Agile suits projects where details will change. For a fixed, well-documented scope, a plan-first approach can be simpler and cheaper.
- How long should a sprint be?
- The Scrum Guide sets a maximum of one month. Two weeks is a common choice for small teams.
- How many milestones should a project have?
- Enough that each one has a clear deliverable the client can check. For small projects, three often works well: a plan, the build and the launch.
- Can I change method halfway through?
- Yes, if the client agrees. Many projects start with a prototype and move to short cycles once the design is settled.
Talk about the method with your client before the first milestone. Agreeing on how you will work is the fastest way to agree on the work itself.