Written By

Lewis Boyles-White

November 18, 2020 - 5 min read

3 Software Development Pricing Models

One of the first questions we’re often asked is “How much will it cost for software which does X, Y, Z?”. Estimating software with a high level of uncertainty (an MVP for instance) is no trivial task and it’s almost impossible to know all the different risks and challenges at the very beginning of the project; that said some approaches are better than others.

A good place to start can be: “What budget range will let us create a project with a good chance of succeeding”. Let’s look at a few common software pricing models and where they apply best. We’ll make our case for mostly recommending a fixed-budget, scope-controlled approach.

Considering we utilise Agile, due to its many benefits for software projects it’s useful to consider some Agile principles when discussing project estimation, namely (from the Agile Manifesto):

  1. Customer collaboration over contract negotiation
  2. Responding to change over following a plan

Though we value the items on the right, we value the items on the left more. It’s essential to collaborate with our clients and ask questions together like “How can we best utilise the budget to add the most value”.  As development is completed we’ll uncover new information be that user-feedback or a new suggestion for implementing a feature: it’s important to us that we’re able to respond to new information as it gives the project the best chance of success.

Fixed-Budget, Scope-Controlled allows us to work with our customers to ask “How can we use the budget to add the most business value?”. Let’s dig in.


Option 1: Time & Materials 💰

Time and Materials is where there may be a rough development plan and roadmap but where there is no cap on estimate or budget which can often lead to low value features sucking up lots of development time. It can work well to purely add resource to a project.

  • Variable: Timeline, Scope, Quality
  • Assumption: The client is able to afford to keep assigning budget until the job is finished
  • Risk: With the client (the agency has no incentive to operate efficiently or monitor spend)


  • Allows you to quickly assign development resource as there is no need to discover all the technical detail and
  • Can be good when a project needs resource assigned until complete.


  • Can become expensive quickly.
  • Low certainty of output and timelines.

Good for:

  • MVP’s and projects with a high degree of uncertainty at the beginning
  • Projects where user feedback is likely to be useful (desire to respond to new information)
  • Longer-term maintenance/development projects which require dedicated resource available with predictable workflows
  • Adding developers to your existing team to increase resource

Bad for:

  • Companies who need to set timelines and estimate or control the budget. (unless it’s hiring x developers for y time)


Option 2:  Fixed Cost 😬

Fixed cost projects are projects where the development plan, roadmap, technical discovery, scope, timeline and budget are all fixed. It’s very difficult, arguably impossible, to know all the variables and risks that can impact a project from the beginning so this can lead to friction in delivery or the tendency to deliver low-quality work.

  • Variable: Quality.
  • Assumption: The plan is correct and will not change.
  • Risk: On Agency (whereby they respond by inflating cost or ensuring they “technical” meet contractual obligations whilst sacrificing quality and polish.


  • You’ll get a product exactly as defined in a specification (technically meeting the specification).
  • Can be useful for repeatable common development tasks for instance setting up a server or running a penetration test.


  • You’ll encounter problems if you want to make changes to the project, for instance changing or adding a feature. This can lead to further contract negotiation, new costings and longer time-to-market.
  • If there are unexpected difficulty in the project, the quality may suffer. An agency which is committed to a fixed budget, time and scope is likely to neglect QA (or polish) in order to technically (and probably legally) meet their obligations. Unfortunately, quality is likely to be the variable in this instance.
  • This pricing model requires a detailed architecture, development plan, scope and certainty before starting. This means it’ll take longer to get off the ground. If a new feature is identified that could add lots of business value it’s difficult to integrate this without further negotiations and planning making the process cumbersome and stall the project.
  • The agency and the client are fundamentally pointing in different directions with the agency hoping it is overestimated and the client hoping it is underestimated.

Good for:

  • A really predictable small project which has a high level of technical certainty and clear specification, for example, a pen test.

Bad for:

  • A project which has any uncertainty.
  • A project which may change based on feedback or new information.
  • An MVP which needs technical discovery and flexibility.
  • A project where you want to use the knowledge of the development team to develop the project further (an agency is not likely to make suggestions if the project is fixed-scope and instead focussed on technically meeting the original brief).


Option 3: Fixed-budget, Scope-controlled 👌

This keeps the focus on where it belongs; yours and your user’s goals. It allows us to continuously ask “How can we add the most value to this product?”. Working to a fixed budget (this could be a range) means we control the width and breadth of features in order to deliver within the estimate. This can be achieved well using the Scrum Methodology by prioritising tasks, pruning tasks and during sprint planning/refinement. Open communication (we like to onboard our developers and clients into a joint Slack channel), regular meetings and clear development backlogs really help.

Fixing a budget and controlling the scope allows the agency and client to be on the same team; trying to best utilise the budget to develop a valuable product.

How to control the cost of app development: 

  • Prioritise features early on
  • Involve quality assurance early on
  • Plan for the future with a long-term roadmap


  • Allows for a high-level of user-feedback both from team members and wider stakeholders. Some of the most valuable feedback we collect can be in the hands of users and during development. When users suggest great ideas (perhaps better than something else we’d planned to do instead) we think it’s valuable to be able to implement them quickly.
  • Allows financial certainty by fixing the budget whilst still keeping the scope flexible.
  • Timelines are predictable! Using a fixed-budget allows us to assign resource for a fixed period and work to agreed timelines. Though we may alter the scope as we learn we will incorporate this by prioritising features – always working on the highest priority features next.
  • Allows you to take full advantage of your technical partner. As we’re all working together to deliver the best value we can suggest new ways of implementing functionality and new features which could improve the product. We can then decide together if they are worth adding.


  • The scope can be altered if plans change during development (the initial plan may be changed if we all agree on a new route).

Good for:

  • MVP’s and projects with a high degree of uncertainty at the beginning
  • Projects where user feedback is likely to be useful (desire to respond to new information)
  • Companies who want budget & timeline certainty.
  • Companies who want to get the most knowledge transfer and active input from their technical partner.

Bad for:

  • Adding fixed resource to your existing development team.


TL;DR: Fixed-Budget, Scope-Controlled is superior for a project with a high degree of uncertainty that needs to have a controlled budget. Time & Materials is open-ended which can get expensive, but it can work for accessing additional developer resource (team augmentation) and Fixed Cost does not allow for change or learning and requires highly detailed plans; it’s only useful for a project with extreme predictability with little-to-no technical uncertainty.

Read More

Core Blue Records A New 5-Star Rated Review On Clutch

A business’ modern demands can be definitely fulfilled by custom software. Whether your business is big or small, or even you own a startu…

What is Agile?

Agile (adj): used for describing ways of planning and doing work in which it is understood that making changes as they are needed is an impo…

Understanding User Acceptance Testing (UAT)?

User Acceptance Testing (UAT), also known as End-User, Application or Beta Testing, is the final phase of the testing process ahead of relea…