Agile Development for SMBs: Cost, Contracts and Fit

Agile development is a way of building software without fixing every detail up front. Instead, the team works in short cycles of one to two weeks, called sprints, repeating a loop of build, show and adjust until the system takes shape. The bottom line: agile suits projects where the general goal is clear but the details are best settled while using the product, or where you want to change direction based on how users and the market respond. Cost is usually not a fixed total for a finished product. You pay a monthly team fee for as long as you need the team, and a rough guide for a team of two to four people is around 800,000 to 2,500,000 yen per month.

On the other hand, if requirements are firm and you need the total price fixed in advance, or if your side cannot spare time for regular meetings, traditional waterfall development can be the safer choice. This article is written for business owners and non-IT staff. It covers how agile differs from waterfall, how cost works, contracts (quasi-mandate versus contract for work), fit, your role as the buyer, common failures, a pre-order checklist, and a hybrid approach that is often realistic. All figures are rough market guides that vary widely by vendor, scope and team structure.

Waterfall moves through requirements, design, development, testing and delivery in order, top to bottom. Because scope and total price are fixed first, budgets are easy to manage, but changes midway tend to cause rework and extra cost. Agile assumes change from the start and checks working software at the end of every short cycle.

Neither is better in general; choose by the nature of the project. In practice, few projects are purely agile or purely waterfall, and many combine the two, as in the hybrid model described below.

In agile development, cost is usually set not as a price for a bundle of features but as the price of keeping a team running for a month. A typical team has two or three developers, with a project lead or designer joining part of the time. For small and mid-sized business projects, around 800,000 to 2,500,000 yen per month for a team of two to four is one rough guide. This is paid for the team's working time under a quasi-mandate contract, described below.

The idea of a per-person-month rate behind these figures is explained in what a person-month is. Rates vary by role and skill, so the same three-person team can cost different amounts depending on its makeup. When comparing quotes, look beyond the total and ask who joins at what share of their time.

Agile's strength is that you can start small. Rather than building every feature, you build an MVP (minimum viable product) with only the most valuable parts, watch how it is used, and then decide on further investment. The thinking is similar to that in PoC costs.

These are rough guides seen in the market. Actual amounts depend heavily on feature complexity, quality requirements, external integrations, vendor rates and team utilization. Ask several vendors using the same assumptions and compare on equal terms. Typical patterns that lead to extra charges are covered in preventing extra-cost trouble.

A sprint is the basic unit of agile work, lasting one to two weeks. A sprint generally runs as follows.

- Planning: choose, in priority order, which items from the backlog to build this sprint
- Development: build the chosen items, sharing progress and issues in a short daily meeting
- Review: show working software to the buyer and gather feedback, fixes and next priorities
- Retrospective: the team reflects on how it works and improves in the next sprint

For the buyer, the key point is that every review lets you touch working software. You catch the problem of seeing the product for the first time near the end and finding it is wrong, early and in small pieces. Conversely, if the buyer skips reviews, most of the benefit of agile is lost.

Software contracts fall broadly into two types. Under a contract for work (ukeoi), payment is for a completed deliverable, and the vendor bears responsibility for completion and for nonconformity. Under a quasi-mandate (jun-inin), payment is for performing the work itself; the vendor does not promise completion but must carry out the work with due professional care. The differences are explained in quasi-mandate versus contract for work.

Quasi-mandate is common in agile because a contract for work, which requires defining a finished product and a total price in advance, fits poorly when specifications are expected to change. A model contract for agile development, published by IPA (Information-technology Promotion Agency, Japan), is available as a reference. When drafting your own contract, use such public models as a starting point and have a lawyer or specialist review it for your case.

Quasi-mandate is flexible, but costs arise even if nothing is completed. If the buyer does nothing, money can be spent without results. Four measures keep the risk within a realistic range.

- Set a budget cap: fix an overall ceiling and agree that the vendor must consult you before exceeding it
- Make sprint reviews mandatory: at each review, confirm results and decide whether to continue, adjust or stop
- Define termination terms: for example, stop from the next sprint or end with one month's notice, with the settlement method written down
- State rights to deliverables: confirm in writing who owns source code, design documents and data, and the terms for any third-party components

Rights to deliverables and the scope of what is handed over (full source code, design documents, environment setup steps) are common sources of later disputes. Besides the contract, ask that each sprint's output be placed somewhere you can access, such as a code repository, so that switching vendors later does not leave you stuck.

Agile suits the following kinds of projects.

- New ventures or services where the right answer is unknown until tried
- Process improvements you want to refine while people use them
- Products where feature priorities should change according to market or customer response
- Projects you want to start small and invest more in once results appear
- Cases where your side has someone who can review and decide continuously

Agile tends to be harder in these cases.

- Specifications strictly fixed by law or contract, leaving little room for change
- Budget approval that requires a confirmed total price in advance
- Cases where the buyer cannot spare a few hours a week for meetings
- Large core systems with many connections to existing systems that need a full design first
- Organizations where several decision-makers must agree, making priorities slow to settle

Even if a project falls under the second list, agile is not impossible. You will need to separate parts to be fixed from parts to be kept flexible, as in the hybrid model below.

What decides the outcome of an agile project is the buyer's product owner: the person responsible for what is built and in what order. They do not have to be an IT expert, but ideally they understand the business well and have authority to make decisions inside your company. This is a role you cannot hand to the vendor.

As a guide, the product owner needs to set aside a few hours a week for sprint planning, reviews and answering the team's questions, and more on larger projects. If you assume you can fit this between regular duties, replies get delayed, development stalls, and you pay for idle time. Block the time in advance.

- Handing everything over: assuming agile means the vendor will flexibly build what is needed, leaving both requests and decisions to them, and ending up with something nobody wanted
- Unclear goal: starting without defining what success looks like, so sprints pile up with no end in sight and costs keep running
- No budget cap: because payment is monthly, without a ceiling and review points the total can far exceed expectations
- Skipping reviews: being too busy to attend, noticing drift too late, and facing large rework in the later stages
- Too little documentation: misreading agile as no documents, so no design or operating notes remain and nobody can maintain the system after staff or vendors change

Agile values working software over comprehensive documentation, but that does not mean documentation is unnecessary. Ask in the contract for the minimum records needed for maintenance and handover, such as an architecture diagram, key specifications and operating procedures.

For SMBs that want a view of the total cost but also flexibility on details, a hybrid model is realistic. Requirements and basic design are settled fairly firmly first, done under a contract for work or a short quasi-mandate. Development then proceeds agile, building and checking high-priority features in small steps.

This gives management a rough budget and an overall picture up front while still letting you respond to issues found during development. For how to put together a requirements document or request, see RFP basics.

- You can state in one sentence the problem to solve and what success looks like
- A product owner is named in-house, and their manager has agreed to a few hours a week
- You have set an overall budget cap and review points (for example, every three months)
- The plan is to start with a small MVP and decide further investment from the results
- The vendor has explained the contract type (quasi-mandate or contract for work) and why
- Early termination terms and settlement rules are written in the contract
- You have confirmed that source code, design documents and data belong to your company
- The frequency of sprint reviews and who attends are decided
- The deliverables include the minimum documentation needed for handover
- You have checked that the team structure holds even if individual staff change