Software Development Pricing Models Explained

There are four software development pricing models in common use: fixed price, time and materials, a dedicated team retainer, and milestone-based pricing, which is a hybrid of the first two. They differ less in what you pay than in who carries the risk when the work turns out to be bigger, smaller or different from what everyone assumed. The right model follows from one question: how certain is the scope today? Fixed price suits a well-defined deliverable, time and materials suits discovery and change, a retainer suits ongoing product work, and milestones suit a large project that can be defined one phase at a time. The rest of this guide shows how to tell which situation you are in and what to put in the contract.

Four models

Every vendor describes these slightly differently, and some invent names, but the underlying software development contract types come down to these four.

Fixed price

You agree on a scope, a deliverable, acceptance criteria and a total price before work begins. The vendor absorbs overruns; you absorb the cost of anything you want that is not in the scope, which goes through a change request. A fixed price contract for software works when the scope can be written down precisely enough that two reasonable people would agree whether it has been delivered.

Time and materials

You pay for the hours or days worked, at agreed rates per role, usually with a budget cap and a reporting cadence. A time and materials contract puts the risk of scope growth on you and the risk of inefficiency on your ability to see and manage the work. It fits discovery, research, integration with systems whose behavior is unknown, and any project where change is expected rather than feared.

Dedicated team retainer

You pay a monthly amount for a named team, or named individuals, who work on your priorities under your direction or a shared delivery lead. The dedicated team pricing model is time and materials with a longer commitment and a steadier team; in exchange for predictability on both sides, you get people who learn your product instead of a rotating cast. It fits ongoing product development, platform work and anything without an end date.

Milestone-based

The project is divided into phases, each with its own scope, deliverable and price, and each priced only once the previous phase has made it definable. The first milestone is often a discovery or design phase on time and materials that produces the fixed-price scope for the next. This is the model most large projects should use, and the one least often offered because it requires the vendor to re-quote several times.

Who carries which risk

The fixed price vs time and materials debate is really a debate about risk allocation. The table makes that explicit.

Risk	Fixed price	Time and materials	Dedicated team	Milestone-based
Scope turns out larger than expected	Vendor, within the agreed scope; you, for anything outside it	You	You, but absorbed into the roadmap rather than a change request	Shared: the next milestone is re-scoped
Requirements change mid-project	You, through change requests that cost time and goodwill	You, but change is cheap to make	You; the team simply reprioritizes	Mostly you, contained to the current phase
Vendor works inefficiently	Vendor	You, unless you can see the work	You, unless the team is visible and reviewed	Vendor within a fixed phase; you within a T&M phase
Quality is cut to protect margin	You; the usual failure mode of fixed price	Low; there is no margin to protect	Low	Moderate in fixed phases
Budget predictability	High, for the agreed scope	Low without a cap and reporting	High per month, open-ended in total	High per phase
Speed to start	Slow; the scope must be written first	Fast	Fast once the team is assembled	Fast, because phase one is small
Vendor incentive	Finish within scope, resist change	Keep the engagement going	Keep you renewing, which means keep you happy	Earn the next phase

Two things in that table are worth underlining. Fixed price moves overrun risk to the vendor, but a vendor under pressure protects itself by cutting quality or testing, so you carry the risk in a different form. And time and materials is only as safe as your visibility: with weekly demos, reviewed code in your repository and a cap, it is the lowest-risk model there is.

Choosing by project certainty

Lay projects on a line from fully defined to largely unknown, and the model follows.

• Fully defined. A rebuild of a system that exists, an integration to a documented API, a website from approved designs, a well-specified module. The scope can be written, tested and accepted. Use fixed price, and insist on acceptance criteria you can verify.
• Defined outcome, uncertain path. A new product with a clear first version, a migration of a system that is only partly understood, an application that depends on data nobody has profiled yet. Use milestones: a short time-and-materials discovery that ends in a fixed-price scope for the build, then repeat for each phase.
• Ongoing and evolving. A product after launch, a platform used by several teams, a backlog that will never be empty. Use a dedicated team. Review the roadmap monthly and the team composition quarterly.
• Largely unknown. Research, a proof of concept, a rescue of a failing project, a data cleanup whose size nobody knows. Use time and materials with a cap and a weekly checkpoint, and convert to another model once the unknowns are resolved.

The common mistake is to demand fixed price for work in the second or fourth group because it feels safer. It is not. A vendor asked to fix a price on an undefined scope will either pad it heavily or underbid and then fight every change. If you need budget certainty for uncertain work, buy it in phases rather than in one number, and compare vendors on how they handle the phase boundaries rather than on the first quote. The related question of whether to build at all is covered in our guide to build vs buy software.

Organization size changes the engagement, not the logic. A founder usually starts with a fixed-scope first version because cash is finite and the deliverable is clear. A growing company most often ends up with a dedicated team once the product is live and the backlog is permanent. A department inside a larger organization often has procurement rules that favor fixed price, and milestone-based pricing is usually the way to satisfy them without pretending the scope is known.

Contract clauses that matter

The pricing model gets the attention; the clauses below decide whether it works. They apply whichever model you choose.

• Scope and acceptance criteria. For fixed price and milestones, a statement of work that says what will be delivered and how you will test that it was. Vague scope is the root of almost every fixed-price dispute.
• Change control. How a change is requested, estimated, approved and priced, and how long the vendor has to respond. A good process makes change routine; a missing one makes it a negotiation.
• Rates, roles and reporting. For time and materials and retainers, the rate per role, who is on the team by name or seniority, a budget cap, and what you receive each week: hours by task, a demo, and a view of the backlog.
• Intellectual property. Everything built for you is assigned to you on payment, including source, infrastructure definitions and documentation, with any vendor-owned tooling or open-source components listed as exceptions.
• Repositories and accounts in your name. Code, cloud accounts, domains and third-party services are created under your ownership from the first week, so an exit is a handover of access rather than a transfer.
• Payment schedule. Fixed price is usually tied to milestones or acceptance, not calendar dates. Retainers are monthly in advance or arrears. Avoid large deposits against undefined work.
• Warranty and maintenance. A defect-fix period after acceptance, and a separate maintenance agreement with defined response expectations if the vendor will keep running the system.
• Team continuity and subcontracting. Notice before named people are replaced, no subcontracting without consent, and a knowledge-transfer obligation on exit.
• Termination. Notice periods on both sides, payment for work completed, and an orderly handover of code, documentation and credentials.

Rates matter less than people assume. A lower rate with a weaker team, more hours and less visibility costs more than a higher rate with a smaller, senior team that ships. Our guide to how much it costs to hire a developer covers what drives the rate; the guide to writing an RFP for software development shows how to ask vendors for the clauses above before you compare numbers.

Where PS3G fits

PS3G works under all four models and will say which one fits before quoting. A defined deliverable is scoped and priced as a fixed-scope project; discovery and rescue work run on time and materials with a cap and weekly reporting; ongoing product and platform work runs as a dedicated team through our staff augmentation and dedicated team service; larger programs are priced in milestones, each defined by the one before. Our software development and maintenance service covers the build and the maintenance agreement that follows it, with code in your repositories and accounts in your name from the first week. We start the same way regardless of model: a first conversation, a short assessment, a written proposal.

Related reading

• Build vs Buy Software: A Decision Framework for Growing Companies
• How Much Does It Cost to Hire a Developer? Rates by Model and Region
• RFP Template for Software Development (With the Questions That Matter)

Frequently asked questions

Which is better, fixed price or time and materials?

Neither is better in general. Fixed price is better when the scope can be written precisely and tested, because it gives budget certainty for that scope. Time and materials is better when the work involves discovery or expected change, because change is cheap and the vendor has no incentive to cut quality. Most larger projects are best served by a mix: a short time-and-materials discovery followed by fixed-price phases.

What is a dedicated team pricing model?

A monthly fee for a named team that works on your priorities for as long as you renew. It is time and materials with a longer commitment and a stable team, which gives you people who know your product and gives the vendor predictable work. It suits ongoing product development, platforms and permanent backlogs, and it is usually reviewed monthly for priorities and quarterly for team size and composition.

How do I protect myself in a time and materials contract?

With visibility and a cap. Require code in your repository with reviewed pull requests, a demo every one or two weeks, hours reported by task, a budget cap that cannot be exceeded without written approval, and named people with notice before replacement. With those in place, time and materials is the lowest-risk model available; without them, it is an open invoice.

Can software development pricing models be combined in one project?

Yes, and most larger projects should combine them. The usual pattern is milestone-based: a discovery or design phase on time and materials produces the fixed-price scope for the build phase, and the pattern repeats for each phase. After launch, the work often converts to a dedicated team. Combining models gives budget certainty one phase at a time without pretending the whole project is known at the start.