Fixed Price, Time and Material, or Retainer? Choosing a Software Project Pricing Model

When a business asks for a software development quote, the answers often look impossible to compare. One vendor offers a fixed price for the whole project. Another bills per hour of work. A third proposes a fixed monthly fee for a team. The difference is not just about the numbers, but about who carries the risk when requirements change, the work turns out harder than expected, or the schedule slips.

Understanding pricing models helps you choose one that fits the project, rather than simply the one that looks cheapest in the proposal. This article compares the three most common models, fixed price, time and material, and retainer, along with hybrid models, the risks of each, and the questions to ask before signing a contract.

Summary

• Fixed price suits a clear and stable scope; risk shifts to the vendor, and changes are usually charged extra
• Time and material suits evolving requirements; it is flexible, but the final budget is less certain without oversight
• A retainer suits ongoing needs such as maintenance and gradual development
• Hybrid models, such as a paid discovery phase by time followed by a fixed price build, are often the most sensible
• Any model still needs a written scope, handover schedule, acceptance criteria, and a clear change mechanism

Why the pricing model matters more than the number

Two quotes with the same figure can lead to very different outcomes. A cheap fixed price with a vague scope often ends in arguments about what is included, sacrificed quality, or ballooning change costs. A reasonable looking hourly rate can end up expensive without scope control and progress reporting. So the first question is not "how much" but "who carries which risk".

Many of the project failures discussed in the article on why software projects fail are rooted in a mismatch between the nature of the project and its commercial model, such as demanding a fixed price for requirements that are not yet clear.

Model 1: Fixed price

Vendor and client agree scope, schedule, and total price up front. The client pays in agreed stages, usually tied to milestones such as a deposit, completed design, and handover.

Advantages

• The budget is easy to predict and to get approved internally
• The risk of overruns from work harder than expected is carried by the vendor
• Easy to compare across quotes if the scope is the same

Disadvantages and risks

• Scope must be very clear from the start, while business needs are often understood only after seeing a prototype
• Every change becomes a negotiation and is usually charged, so clients hesitate to change direction even when they should
• The vendor has an incentive to cut quality, testing, or documentation to protect margin
• Fixed price quotes often already include a risk reserve, so they are not always cheaper

Fixed price suits projects with well defined scope, such as a company profile website, a specific integration, or a migration with clear specifications. The quality of the requirements document is decisive, so also read how to write a software requirements document.

Model 2: Time and material

The client pays for the time actually used, usually an hourly or daily rate for each role, plus certain expenses if any. The vendor gives an estimate, but the estimate is not a binding cap unless agreed as such.

Advantages

• Flexible to change, so it fits the iterative methods discussed in the article on [Agile or Waterfall](/blog/agile-atau-waterfall-metode-proyek-software-untuk-bisnis)
• The client pays for work done, not for a risk reserve
• The project can start sooner without waiting for a full specification
• Priorities can change midway based on what is learned from users

Disadvantages and risks

• The final total cost is uncertain and can balloon if scope is not controlled
• The client carries the risk of work taking longer than estimated
• Requires transparency: timesheets, progress, and verifiable results
• Needs someone on the client side who actively manages priorities and accepts deliverables

To keep the risk under control, set a budget cap per period, review results regularly in routine demos, and ask for reports that connect hours with completed features. The start small approach in the article on MVPs for business apps fits this model very well.

Model 3: Retainer

The client pays a fixed periodic fee, for example monthly, to secure a certain capacity from the vendor: a number of hours, a dedicated team, or a service package with guaranteed response times. A retainer suits ongoing needs such as maintenance, bug fixes, security updates, and gradual development of small features.

Advantages

• A monthly cost is easy to budget, and a long relationship builds the vendor's understanding of your system
• Faster response to urgent problems because capacity is already reserved
• Suits maintenance, as discussed in the article on [application maintenance after launch](/blog/pemeliharaan-aplikasi-setelah-peluncuran)

Disadvantages and risks

• Unused hours or capacity may expire, so you pay for something you do not use
• Without a priority list, capacity is often absorbed by small, low impact work
• Needs clarity on what is included in the retainer and what is charged separately

Hybrid models that often make the most sense

Many successful projects combine models. A common pattern is a short discovery and design phase on time and material, producing scope, a prototype, and a sharper estimate. After that, the clear parts are built at a fixed price per phase, while parts still evolving continue on time and material with a budget cap. After launch, maintenance continues under a retainer.

1. 01A short discovery and prototype phase with written outputs: scope, priorities, and estimate
2. 02Build the core modules at a fixed price per phase, paid by milestone
3. 03Additional features on time and material with a monthly budget cap
4. 04Ongoing maintenance and improvement under a retainer

This phased approach reduces the up front bet and gives both sides a chance to assess fit before a large commitment. Additional considerations for cross regional projects are in the article on outsourcing software development to Indonesia.

How to choose the right model

• How clear is the scope? If clear and stable, fixed price makes sense; if still evolving, choose time and material or a phased approach
• How much tolerance is there for budget variation? A rigid budget favors fixed price or time and material with a cap
• How actively can your team be involved? Time and material demands consistent client involvement
• Is the need one off or ongoing? Ongoing needs fit a retainer
• How much do you trust the vendor? A new relationship benefits from a small phase as a trial

What must be in the contract, whichever model

The pricing model is only one part of the contract. Equally important points are covered in the article on key points of a software development contract. Make sure at least the following are written down:

• Scope of work and what is not included
• Testable acceptance criteria, and the [user acceptance testing](/blog/uat-pengujian-sebelum-aplikasi-diluncurkan) process
• Schedule, milestones, and the consequences of delay from both sides
• A scope change mechanism: who proposes, how the estimate is made, who approves
• Ownership of code, designs, and data, plus access to repositories and environments
• A warranty period for bug fixes after handover and the maintenance cost afterwards
• Confidentiality, data security, and termination terms

Red flags in a quote

• A price far below other quotes without any explanation of scope
• Scope written in generic terms such as "complete system" with no feature list
• No explanation of testing, security, and documentation
• An hourly rate with no estimate, cap, or reporting
• Code or access withheld until full payment without a clear escrow arrangement
• The vendor refuses to discuss scope changes before the contract is signed

If a project is already running and feels stuck, the article on rescuing a stalled software project covers how to reassess the contract and the options available. For a fuller picture of cost, including costs beyond development, read calculating the real cost of a software project and the checklist for choosing a software house.

Frequently asked questions

Which of the three models is cheapest? None is automatically cheapest. Fixed price may include a risk reserve, time and material can balloon without control, and a retainer is expensive if capacity goes unused. Compare total cost of ownership, not just the quote.

Can you switch models midway? Yes, as long as it is agreed in writing. For example, start with time and material for discovery, then move to fixed price once the scope is clear.

How do you avoid cost overruns on time and material? Set a budget cap per period, ask for regular demos, prioritize the feature list, and review timesheets with the vendor.

Should the warranty be written into the contract? Yes. Define its length, the types of issues covered, and response times, so there is no dispute after handover.

What is a reasonable retainer term? Start with a short period with periodic review, then extend if the results are satisfactory.

Conclusion

No pricing model is always best. Fixed price gives certainty when scope is clear, time and material gives flexibility when requirements evolve, and a retainer keeps the system healthy after launch. Many projects run best with a phased combination of all three. Choose a model based on scope clarity, budget tolerance, and how involved your team can be, then make sure the contract sets out scope, acceptance criteria, and the change mechanism clearly.