Is a fixed price quote right for your software project?

If — like many of our clients — you're new to developing custom software, you'll have some questions about how it all works.

I always recommend asking as many questions as you can before starting your project. But custom software projects (including mobile app development) often begin with unknowns hanging in the balance. This is where new software clients tend to opt for a fixed price quote:

• You might be unfamiliar with the custom software / app development process
• You might not fully understand your target users' requirements (yet)
• You might not be sure if the project will work, or is even feasible
• ...the list goes on

Fixing project costs lets you hedge your bets against those unknowns. A fixed price software quote also means a fixed project scope, so sometimes new ideas can get abandoned. In some cases, those new ideas could make or break your project. How do you capture new opportunities when project costs are fixed?

This article outlines some of the pros and cons of fixed price custom software quotes (i.e. fixed scope). Fixed price quotes can be an effective tool when developing small apps or limited-scope custom software. But, is a fixed price right for your project?

Broadly, this article covers:

1. Why fixed price software projects need a detailed specification or they risk failure (with statistics)
2. How software companies deal with the risk of fixed price projects
3. How shorter development sprints can catch problems sooner
4. 'Timeboxing' — sticking to a limited budget whilst working in order of priority
5. Other considerations: supplier trust, flexibility, maintenance, and technical debt

Disclaimer: I'm a staunch advocate of 'straightforward billing' (time and materials based on a day rate). I've seen it work for every project at Codevate for the last 7+ years. Some of those projects are valued in excess of seven figures, and some are patent pending — no small feat! I'm an experienced software consultant and have worked on both fixed and flexibly priced (estimated) software projects. Read on to get my two cents' worth.

Before we dive in, if you've found this post in your search for a software quote, feel free to drop us a line. Alternatively, reach out to me directly on LinkedIn.

You can also read about our bespoke software and mobile app development services.

Why fixed price software projects need a detailed specification or you risk failure (check out these statistics)

As I mentioned in the intro, there can be many unknowns baked into a software project. The main aim for any fixed price quote is to mitigate financial risk. So, agreeing a fixed price for a fixed outcome keeps things clear. The aim is to know exactly what you're getting and how much the software project costs.

This may come as a surprise, but (according to a report by The Standish Group):

• 31.1% of software projects are cancelled before they’re completed;
• 52.7% of projects run over budget to almost 2x the original amount (189%);
• and on average only 16.2% of software projects are completed on time and on budget 🤯

Another report by Geneca suggests:

• Up to 75% of software projects fail;
• Up to 80% of respondents said that they spend half their time reworking the software;
• Less than 20% think their requirements are aligned with the business;
• and up to 77% don't know how to tell when their project is 'done'

A 75% failure rate might seem surreal. But, according to Simply Business, around 80% of UK small businesses fail within the first year. That puts things into perspective.

That's why we take the requirements gathering and specification process so seriously at Codevate. To date, we have a 100% completion rate across both our bespoke software and mobile app development project work. We're meticulous at the specification stage, and we only employ skilled senior developers.

It's important to keep in mind that a fixed price generally means a fixed scope for your project. A change of plans will mean a change in price (and sometimes project timeline). You might not be able to afford those changes if your budget is already set or your project is time sensitive.

It's not uncommon for software developers to uncover new opportunities during the course of the project. These can be missed requirements, an issue with a third party library or API, or new innovations etc. So it can be wise to budget extra; we generally recommend to set aside an optional 10–20%, just in case.

For projects where flexibility is required — like research & development projects — a fixed price isn't feasible. There are too many moving parts.

For a fixed price software quote to be successful, each 'sprint' should be planned in high detail. No stone can be left unturned; again, if plans need to change, you'll have to renegotiate costs or stick to your original guns. If you're open to changes in price, your project might be better suited to a more flexible approach.

nb. "Sprints" are sometimes called phases, stages, cycles, versions, iterations, etc. These are smaller bursts of development that make up your project.

If your software quote is a single invoice line, make sure to get a second opinion! There should be some feature prioritisation or a development roadmap. Unless your software project is only a few weeks long, it's standard practice to develop software in stages (sprints). More on this later.

A lack of detail or missing feature(s) could leave you with a half-finished project. If you can't afford to finish your project, you've made a 100% loss and the fixed price has backfired. 🚨

It's wise to read the full quote (or software proposal/specification) to make sure it's what you had in mind. Once you're happy with it, you're good to go!

How do software companies handle projects with a fixed price quote?

When you agree to a fixed project price, the financial risk is shifted onto the software company.

Why? Well, if something goes wrong the project can make a loss for the software company. For instance, if the company's estimates are wrong, they could run out of time before the project is complete. Either the project fails, the software company completes it at a reduced margin (or a loss), or you have to pay more.

Software companies can handle this in a few ways. Usually, it's with an increased estimate before the project starts. Sometimes it's with corner-cutting if the project is ongoing and the pressure is on. Remember the project management triangle?

When your software project costs are fixed, you limit your options. Either you reduce the project scope to fit the time and budget, or the quality of your software has to suffer.

Ultimately, quality is remembered long after price is forgotten.

💰 Increased estimates: how software companies account for uncertainty in quotes

It's not uncommon for software estimates to be multiplied by an "uncertainty factor". This is normally done with the best of intentions. Every software developer knows that each project has a level of uncertainty involved.

With bespoke software, starting the same project with the same team a few months later can produce a different result. This is because technologies and best practices are always evolving. So, it's standard practice to assume some project unknowns will crop up. After all, a failed project is in nobody's best interests.

In some cases, software agencies can add 10–20% on to their estimates. Where uncertainty is much higher, agencies can increase their estimates as much as 2–3x! This can be due to lack of detail in the project plan, high complexity, or required R&D.

And what happens when the project only takes half the expected time (or less)? Well, a fixed price is a fixed price!

To get super accurate estimates you could approach a company who builds similar software time and time again. However, in the world of bespoke software, this is rare to come by. This is because it's common to develop bespoke software when something hasn't been done before. (And your project requires an element of R&D or evolution).

With enough searching, you can likely find a custom software company that's worked with your requirements before. However, it's possible they have a non-compete in place with a competitor. If not, they could be a good option for your project. But it can be hard out-innovate your competitors using the same supplier.

I'll elaborate. A single-focus (or "cookie cutter") software company likely solves the same problem (or problems) repeatedly. Meaning they likely make their money from selling roughly the same solution every time. Your project will have a higher chance of success from working with a company with a tried-and-tested solution. But, if you're looking to innovate, they may not be the best choice for your software project.

Alternatively, you can work with a software supplier who has worked on similar projects or features. They'll have tried-and-tested knowledge, but likely no non-compete. Moreover, their cross-industry experience can help you out-innovate your competition.

❌ Cut corners: why trust is important in successful fixed price software projects

If the software company's estimate is wrong, a fixed price can incentivise them to cut corners. This can happen if their company is at risk of losing profit and time is running out for the project. In this case, you'll be left with a lower quality app (or software) than you expected. And when your software company is making a loss on your project, nobody wins.

In extreme cases, the company will have to postpone or abandon your project completely. They'll need to prioritise other paying projects to meet their ongoing operational costs. If your supplier can't pay their staff or rent, all of their clients suffer, and their business is in jeopardy too.

What do you do if your project is at risk of abandonment, or is indefinitely postponed? It's important to ensure that the source code (and its copyright) are transferred to you. Without them, you won't be able to continue your project with a new software company.

Cut corners (or missing features) can come from a lack of communication (or clarification) too. In a fixed software project, developers can be reluctant to provide updates. Giving regular project updates can lead to clarification, refinement, and ultimately change. In Agile software projects, this is considered a good thing. But when the project price is fixed, development can turn into a rigid tick-box exercise.

What's worse, is that software companies sometimes purposely low-ball software project costs just to win a contract. Then they have to rely on the sunk cost fallacy to lock you into a project for the longer term. Comparing several fixed price quotes can help you identify these risky situations. I wrote an article on how to get your money's worth in an app development quote which you may find useful.

Fixed prices can encourage unscrupulous companies to maximise profit margins through cut corners too. If the company believes the project is "doomed either way", it may not put the required effort in. Although this will be extremely rare, it's wise to be fastidious when selecting a software supplier.

Without an independent software consultant, you likely won't know your project was built with cut corners until it's too late. Frequent communication with your software supplier helps, but an element of trust is always going to be involved.

What can you do to avoid cut corners and increased estimates in your fixed price project?

The best way to avoid overly-increased cost estimates or cut corners? Plan fixed price software projects with as much detail as possible.

This is usually done with up-front consultancy or project discovery sessions. Depending on how long these sessions take (or how many are needed), they may be chargeable.

At Codevate, we offer our first meeting free of charge, which can last anywhere between 1–2 hours. A skilled software consultant can capture a lot of detail in this initial session. We then exchange further information via email and a follow-up call. You can get in touch here if you'd like to book in a free meeting.

For high-complexity projects, we host chargeable discovery workshops with a dedicated software consultant. These allow us to take a deep dive into your software (or app) idea and refine it before the project starts.

Getting your software spec as good as possible early on is important. Oftentimes its worth paying for, as poor specifications or missed requirements can cripple your project down the line. A stitch in time saves nine, as they say.

Comparing multiple fixed price quotes at roughly the same cost can come in handy. With enough (legitimate) quotes, you'll notice if you've received a bloated estimate. Quotes that come in significantly lower should be met with scrutiny.

For completeness, in our time and materials projects, we often agree on an estimated timeline and rough costs. We schedule 'fact find' days at the start of the project to refine the proposal, clarify details, and solve unknowns. This works well for projects where the right 'fit' needs to be discovered and refined through ongoing development and feedback.

👌 Shorter development sprints minimise risk and project 'unknowns'

Longer development sprints will have more unknowns and require more detailed planning. So, keeping your fixed price development sprints as short as possible makes sense. They're easier to plan, and if an estimate is wrong it will have a much smaller impact on the project timeline.

For fixed price projects, I'd recommend sticking to development sprints of around 1–3 weeks long. Four weeks at the absolute maximum. Most features can be broken down into multiple sprints if required.

In time and materials projects, it's not uncommon to have development cycles up to six weeks long. In his book Shape Up, Ryan Singer writes about six-week development cycles being the sweet spot:

"Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely."

In Codevate's time and materials projects we work to 1–6 week phases. This helps us organise our development roadmaps to deliver working software early and often. Smaller phases give us the flexibility to incorporate stakeholder and user feedback into the next. In turn, this ensures a better product-market fit.

You can do this on fixed price projects too, but you'll need to guess how much project feedback you think there will be. Getting this right can be tough, as your end users can effectively have unlimited feedback. You really want to listen to your users. After all, if they're not happy with the software, why should they use it? End-user or market feedback is the key to success for almost all custom software projects.

Generally, the shorter the development sprint, the sooner you'll get a project update. This helps to keep the communication flowing, and lets you catch problems sooner rather than later.

Project flexibility is an important consideration. In my opinion, responding to change is integral to the success of every custom software project. That's why Agile methodology was created. Fixed price projects can be a little flexible with shorter development cycles and pre-arranged feedback sprints. However, by their very nature, they're designed to be rigid.

⏱ 'Timeboxed' development: an alternative to traditional 'fixed price' projects

A good alternative is to timebox your development project instead. Timeboxing is essentially a fixed price software project with a variably-scoped specification. You agree a fixed timeline based on your budget and the company's (or developer's) day rate. Your developer then aims to deliver as much as possible within that time frame. This is generally based on an order of priority.

For example, let's say your budget is £20,000 and (for argument's sake) the company's rate is £500 per developer day. That's two months (40 days) of development time to get as much done as possible.

Timeboxing works particularly well for projects with 1–2 core features bundled with lots of nice-to-haves.

It also works well for projects that can deliver business value or a return on investment (ROI) early on. You develop the highest-impact features first, prioritise ROI, and aim to create the best software for your budget.

A good use case is found in businesses that regularly fill out a series of audit forms. It stands to reason that some audits will have a higher business impact than others. So, we prioritise the features (audits) using an impact-effort matrix:

Source: https://uxplanet.org/lightning-decision-jam-a-workshop-to-solve-any-problem-65bb42af41dc

(I also talk about these in my article on how to get your money's worth in your app development quote)

Focusing on high-impact, low-effort features lets you stick to a budget and solve the most important issues. You get to have your cake and eat it!

Of course, this only works with projects where you can postpone some of the lower-value features until you've made a ROI. Once you've made your return, you can afford to invest in the next set of features. This creates a sustainable long-term project for your business.

For any custom software project to work, an element of trust needs to exist between client and supplier. Quite often, a fixed price quote is an attempt to bandage a client-supplier relationship that's low on trust. If this sounds like your project, shouldn't you find a different supplier (or approach)?

So, what's the best way to build trust with a new software company? Check out their reviews, have them demo past work, and spend some time working on the software specification together. Personally, I look up suppliers (and clients) on LinkedIn to see if they have some public testimonials. You can find my LinkedIn here.

Getting a fixed price quote might seem like a good idea to start your project off and test the waters. (And in many cases, it can be). But if you decide to grow your project over the longer-term, the software company may suggest a full rebuild. A timeboxed approach could help here; your costs can be fixed in the experimental stages of your project.

Technical decisions made early on in a software project can have a huge impact on future maintenance costs. As technology changes over time, those early decisions accrue "technical debt". If your project was built on a tight budget, it might not be built to last.

Fixed prices can work for shorter, low-complexity software projects. Or for projects where all the requirements are known in advance. But what about complex projects that need to evolve through testing, user feedback, and experimentation? I'd recommend finding a time & materials supplier that you can trust. Just make sure that they can demonstrate they've got what it takes to deliver your software idea to the market.

Still convinced you need a fixed price software quote with a fixed scope? You can still use what I've outlined in this article to evaluate the proposals you receive. Make sure to get multiple quotes (3–5) from different software suppliers. If you want them to come in at the same price point, you'll need to give an indication of your budget.

Hopefully this article has shed light into some key factors to consider when getting a fixed price software quote. If you've already got your quotes, we're happy to spend some time on the phone giving a quick at-a-glance second opinion. Alternatively, feel free to take advantage of our free initial meeting by contacting us here.

If you're still reading around, you might find our other articles useful:

1. Getting a quote from a UK app developer? Try these 3 alternatives to common questions
2. Do you need senior software developers on your project?
3. How to get your money's worth in an app development quote