"During a meeting with the software development agency, they told us, 'We will proceed with agile this time.' Is that actually good news for us? When we asked for an estimate, they mentioned there are parts you can't predict until you start, and honestly, not knowing the exact budget makes us anxious"—we received this consultation from a business owner outsourcing custom system development for the first time. Software development generally falls into two primary methodologies, and the choice dramatically alters budget visibility and the client's required involvement. Handing over a project without understanding this difference often leads to misalignment later.
You do not need to memorize methodology names. What matters is recognizing which approach suits your project and ensuring your organization is prepared to handle the associated risks. In this article, we break down those decision criteria with minimal jargon.
"Decide everything before building" vs. "evolve while observing"
The two approaches differ fundamentally in the following ways.
| Approach | Features | Suitable projects |
|---|---|---|
| Waterfall | Lock in all specifications upfront and execute strictly to plan | Projects where requirements are crystal clear and changes are undesirable |
| Agile | Build working increments in small iterations, adjusting priorities as you go | Projects where the optimal solution needs to be discovered along the way |
Waterfall is like creating complete architectural blueprints before laying a single brick. Because everything is determined upfront, total costs are easy to forecast, but requesting changes after construction starts becomes very expensive. Agile, on the other hand, is like building a minimally habitable home and adding extensions while living in it. While resilient to change, the project will never finish unless the client defines what constitutes completion. Neither is inherently superior; the choice depends on project characteristics and how actively the client plans to participate.
Understanding the anxiety behind "unpredictable budgets"
The concern about unpredictable budgets mentioned earlier frequently accompanies agile projects. However, this does not mean costs are completely open-ended; rather, it stems from the philosophy of deciding what to build within a fixed budget as you progress. For example, agreeing to "build the highest-priority features within a 3 million yen budget over three months" keeps the total expenditure fixed while allowing feature scope to remain flexible.
What is required of the client here is resisting the urge to continuously pile on extra features. Maximizing outcomes within budget requires prioritizing and making conscious trade-offs. This mindset is discussed in detail in our guide to scope design to avoid overbuilding. Conversely, if requirements are finalized from day one and will not change, locking in the total price through waterfall provides greater peace of mind. Market rates and contract models are covered in our system development procurement guide.
How development approaches changed now that AI has accelerated coding
In an era where AI assists in writing code, delivering working software early has become dramatically faster. Prototypes can be generated in days, creating great synergy with agile workflows where teams decide while inspecting actual software. However, building faster introduces its own trap: accumulating features without understanding their internal structure makes future modifications nearly impossible.
This is precisely why, even in agile workflows, clients must verify that deliverables are clearly documented and explained. To ensure development agencies perform meaningful reviews rather than perfunctory checks, refer to our guide on identifying effective code reviews. If rapid development turns into a black box, the risk of vendor lock-in if the agency becomes unreachable escalates significantly.
Focusing on "what your company must do" rather than just picking a label
Selecting a development approach is not a decision to be delegated entirely to the vendor. Waterfall demands the responsibility of finalizing specifications upfront, while agile requires the responsibility of making continuous priority calls on the fly. When a development agency proposes an approach, ask them: "Under this model, what decisions will our team need to make, and when?" An agency that can answer this specifically truly understands the methodology they are proposing.
"We were told to use agile, but we're worried about cost predictability," "We don't know if we can start development before requirements are finalized," or "Development is fast, but we fear the software will become a black box"—if you have these concerns, feel free to consult GleamHub's system development and DX support. We will help determine the right approach for your project and clarify your responsibilities as a client.
