On a Friday afternoon, the owner of a logistics company in Bandar Lampung answered a call from his IT team. The delivery tracking system promised in six months was only 40 percent done — after eight months. The budget was almost exhausted. When he asked what could be fixed before launch, the answer stopped him cold: "We already built the wrong module from the start, because requirements changed halfway through."
That failure was not about an incompetent team. It was about methodology. The project ran on the classic pattern known as waterfall: all requirements locked in at the beginning, executed in sequence, with results only visible at the very end. Meanwhile, the business changed, competitors shipped new features, and customers started asking for things that were never on the requirements list from eight months ago.
This article breaks down the two most common software development approaches — waterfall and agile — in language you do not need an engineering degree to follow. Not to declare one superior, but to help you choose the right one for your next project, with honest numbers on what each costs in the Indonesian market.
Two Different Philosophies
Before diving into details, let us clear up two words that are often misused.
Waterfall: Everything Neat at the Start
Waterfall is the most traditional approach, named for how its flow runs in one direction, like water cascading from one level to the next: requirements analysis, design, development, testing, then launch. Each phase must finish before the next begins, and every phase is documented thoroughly.
The closest analogy is building a house. You do not start painting the kitchen before the foundation and roof are done. Every stage depends on the one before it, and changes mid-course are expensive because they mean tearing apart finished work.
Agile: Incremental and Always Adapting
Agile was born from frustration with the waterfall model. The idea: instead of planning everything up front and hoping nothing changes, run the project in small pieces called sprints — typically one to four weeks. At the end of each sprint, you have a piece of software that actually runs, can be seen, tested, and given feedback. That feedback steers the next sprint.
The analogy: writing a novel chapter by chapter and showing each chapter to your editor for input, instead of writing the whole manuscript and handing it over at once. You do not wait a year to find out whether the story works.
How the Two Differ: A Comparison Table
To understand the practical difference, compare both approaches across dimensions you feel directly as a business owner.
| Aspect | Waterfall | Agile |
|---|---|---|
| Planning | All requirements fixed up front, down to the smallest detail | Incremental planning, detailed per sprint |
| Mid-course changes | Expensive and difficult | Accepted, even welcomed as learning |
| Business owner involvement | Minimal, usually at start and end | Continuous, every sprint |
| Visible results | At the end of the project | Every 1-4 weeks |
| Documentation | Complete and formal | Concise and practical |
| Best for | Stable, clear requirements | Changing, unclear requirements |
| Biggest risk | Misunderstanding requirements early | Scope creeping without limits |
This table is not a war between "modern" and "outdated." Both approaches have their place, and the next sections show when each genuinely wins.
Why So Many Projects Fail: The Root Cause
Before choosing a methodology, it helps to understand why software projects fail. Most failures are rarely about technology; they are about requirements that were never understood.
The Standish Group, which has studied software project outcomes for decades through its CHAOS reports, repeatedly ranks "lack of user involvement" and "incomplete or changing requirements" among the top causes of project failure. This is not a finding unique to developed countries; the same pattern shows up in Indonesia. Many projects run for months and then produce a system nobody uses, almost always with the same excuse: "this is not what we imagined."
This is where methodology matters. Waterfall locks requirements in at the start, so if those requirements were wrong or change, the error rides along to the end. Agile builds in small loops that get corrected continuously, so requirement errors surface in weeks, not months.
That does not make waterfall bad. Some projects are safer with waterfall, and forcing agile onto the wrong project creates new problems.
When Waterfall Is Right for Your Business
Waterfall is not an obsolete approach. It remains the best choice in specific situations, and recognizing them can save you real money.
Requirements are clear and stable. If you know exactly what to build, how the flow works, and change is unlikely, waterfall delivers certainty: cost and schedule can be estimated accurately from day one. Real examples: internal systems with fixed rules, like payroll following tax regulations, or reporting modules whose format the government specifies.
Tight regulation and compliance. Banking, healthcare, and government projects often demand complete documentation and process evidence before a system may go live. Waterfall produces exactly the paper trail an audit requires. In Indonesia, government procurement projects frequently require scope locked at the start, so waterfall aligns more naturally with the contracting framework.
Work that merges with physical work. Projects involving infrastructure installation, hardware deployment, or massive migrations often cannot be "tried first" the way software can. Everything must be planned thoroughly before execution — waterfall's strength.
Teams or vendors prefer certainty. Companies used to fixed-price contracts and closed scope often fit waterfall better. The rules are explicit: anything outside scope costs extra, and there is no room for misunderstanding.
Waterfall Costs in the Indonesian Market
Waterfall often sounds cheaper because its initial estimate is firm. The reality is more complex. For a mid-sized project in Indonesia — say, an internal system with 3-5 modules — vendor-built waterfall typically ranges from Rp 50-200 million, assuming scope truly stays stable. If scope changes midway, extras are billed separately and often shock, because changes late in a project are the most expensive kind. For a fuller breakdown of cost ranges by project type, from simple websites to enterprise applications, read our guide to business app development costs.
When Agile Is Right for Your Business
Agile excels in fast-changing environments, and most modern businesses live there.
Requirements are not fully clear yet. If you have the big picture but not the details, agile lets you start with the most important part, see the result, then decide the next direction based on facts instead of guesses. This is highly relevant for new products, features shaped by customer behavior, or projects where the market is shifting.
You need visible results fast. A business in a tight competition cannot wait a year for a system to finish. With agile, a functional first version can arrive in months, even weeks for a small scope, so the business feels benefits before the whole project ends.
Customers or teams keep changing priorities. If business decisions shift often — because of sales data, customer feedback, or strategy — agile keeps those changes cheap. In waterfall, such changes are a budget disaster; in agile, they are a natural part of the working rhythm.
The project is hard to predict. Developing features nobody has built before, integrating with unfamiliar systems, or research-style projects cannot be estimated accurately up front. Agile acknowledges this uncertainty and builds mechanisms to manage it, instead of pretending everything can be pinned down.
Agile Costs in the Indonesian Market
Agile's cost pattern is different. Because scope grows incrementally, pricing is usually per sprint or per monthly team. In the Indonesian market, a healthy agile team (product, developer, and QA) typically runs Rp 40-120 million per month, depending on seniority and headcount. For a small scope handled by one or two developers, costs can be far lower, Rp 10-40 million per month.
Those numbers may look intimidating, but the comparison is unfair without considering what you get: you pay for a system that keeps running and adapting, not for a specification document that gathers dust. Many businesses find the total agile cost for a comparable project lands near waterfall's, with the added benefits of a better-fitting result and lower risk.
The Often-Forgotten Middle Path: Hybrid
This decision does not have to be black and white. Many successful projects combine both.
Waterfall in front, agile behind. The early phase — understanding the problem, setting the broad scope, and agreeing on budget — runs waterfall-style with clear documents. Once the broad scope is agreed, development runs agile: incremental and adaptive. This pattern suits projects with wide scope but fluid details.
Waterfall foundation, agile features. Stable, mandatory system parts, like security and core data integration, are planned thoroughly. User-facing features, which change most often, are built agile so they adapt quickly to need.
The hybrid pattern is often the most pragmatic answer because it acknowledges that not every part of a project carries the same level of uncertainty.
Four Questions to Decide
Rather than copying another company's project pattern, answer these four questions honestly. Your answers will point to the right choice.
1. How clear are your requirements? If you can lay out 90 percent of the requirements without hesitation and they are unlikely to change, waterfall deserves serious consideration. If requirements are still fuzzy or will be shaped by future business decisions, agile is safer.
2. How fast do you need results? If a first version must run within two months, agile is almost always the answer. If the project has a firm deadline further out and stable requirements, waterfall gives schedule certainty.
3. How much change can you tolerate? A business that frequently changes direction — driven by market, data, or strategy — pays heavily under waterfall. A business with fixed rules and rare change benefits from waterfall's certainty.
4. Who will use the result, and can they stay involved? Agile demands regular involvement from the business owner or a delegate. If nobody can give feedback weekly, agile's advantage evaporates, and the more self-contained waterfall becomes the realistic choice.
The Role of External Teams: Vendor or In-House?
The methodology choice is also tied to how you source the people. Many Indonesian businesses choose between building an internal team, hiring a vendor, or combining both. This decision affects which methodology can actually run.
Internal teams run agile more easily because daily communication costs nothing extra. But building an internal team requires recruiting, training, and fixed costs that do not always make sense for a one-off project. Vendors offer flexibility, but the quality of communication and your involvement decide whether agile succeeds. We cover the full comparison in our article on outsourcing vs in-house development.
If you choose a vendor, confirm from the start which methodology will be used and how you will be involved. A good vendor explains its process calmly instead of pushing jargon. Many projects fail not because the methodology was wrong, but because the business owner never knew what was being run until the project was late.
Measuring Success: What You Should Track
Many projects are judged by a single question: "is it done or not?" Yet software project success has more dimensions, and different methodologies demand different metrics.
For waterfall projects, the primary measure is conformance to specification: whether the built system matches the agreed documents, stays on schedule, and stays on budget. These metrics are crisp and easy to track — that is waterfall's strength. Its weakness: it never measures whether the specification itself was right.
For agile projects, the measure shifts to value: how much of what was built actually gets used, how fast the team ships new features, and how much work was wasted on wrong direction. Metrics like cycle time (time from idea to release) and adoption (what percentage of users use a new feature) mean more than a completion percentage.
Whichever methodology you choose, agree on the metrics and how to measure them before the project starts. A project without metrics always looks like it is going well until it is suddenly late — because nobody ever measured its speed.
Why Projects Fail in Indonesia: Patterns We See
Based on patterns we observe across Indonesian projects, failure rarely comes from technology. Three patterns repeat.
First, requirements locked too early. Many businesses spend months writing a thick specification document, then discover halfway through development that half of it is already irrelevant. This is not purely a waterfall failure; it is the failure of locking down something that should have stayed fluid.
Second, agile misunderstood. Conversely, some businesses use the word "agile" without running its principles: no regular involvement, no feedback, sprints running without direction. Agile without discipline is just a neat way to postpone decisions.
Third, choosing by trend. Picking agile because "people say it is modern" without examining the situation, or picking waterfall because "it is familiar" without checking whether requirements are truly stable. Methodology is not a badge of modernity; it is a tool, and the right tool depends on the shape of the problem.
What Happens After the Project Ends
One thing often missing from methodology debates: what happens after launch. Software is not a one-time product; it needs maintenance, updates, and development as the business changes.
This is where the methodology choice echoes again. A waterfall-built system with complete documentation is easier for a new team to understand later, but it resists major change. An agile-built system is usually more flexible because it keeps developing in small loops, but it demands an ongoing maintenance culture.
Whatever you choose, make sure post-launch maintenance and development are in the plan and budget from day one. Software that is built and then abandoned is a wasted investment, regardless of methodology. We discuss the importance of post-launch support in our article on when you need IT consulting.
Frequently Asked Questions
Is agile always more expensive than waterfall?
Not always. Agile's cost per unit of time is higher because it involves a more intensive team and your involvement. But total cost is often comparable or lower, because agile cuts waste from wrong requirements and late-stage changes. A fair comparison must count total cost of ownership, not just the first invoice.
Can small projects use agile?
Absolutely, and they are often the best fit. Small projects have fewer people communicating, so the feedback loop is fast. Agile does not demand a big team; it demands rhythm and involvement, not headcount.
What if my team is used to the old way?
Changing methodology is a culture change, not just a process change. Give the transition time, start with a small low-risk project, and measure real results. Forcing a team into a new methodology without preparation often ends with the same work, just under different labels.
Can Indonesian vendors run agile well?
Yes, but quality varies. Make sure the vendor has real experience with sprints, retrospectives, and routine client involvement, not just the word "agile" as decoration. Ask them to explain how they handle changing requirements mid-project and how you participate each sprint. Concrete answers are the sign of a process that actually runs.
Deciding for Your Project
Back to the logistics company owner at the start of this article. His problem was never waterfall or agile; it was that he was never offered a choice. His team used the pattern they knew, without ever checking whether it fit a business changing as fast as his.
The lesson to take: methodology is not a technical detail you hand entirely to the IT team. It is a business decision that determines how fast you see results, how much you pay for change, and how likely the project is to fail. Taking the time to choose deliberately — instead of following habit — is one of the cheapest investments in your project.
The Kartech team in Bandar Lampung typically starts project discussions by asking about the business problem first, including which development approach makes sense for it, before talking technology or numbers. If you want to discuss your next software project, look at our services, or share your problem through the contact page. We start from the problem, not from the methodology.
