Fixed-price software development contracts: the trials and tribulations

1. What is a fixed-price contract?

A fixed-price contract is an arrangement in which you pay for a given product to be built in a given time for a given amount of money.

In the case of software projects, you pay for a software product you’ve envisioned, and you want to know from the very start what the product will do, how long it will take to build and how much you’ll pay for it.

2. The benefits of a fixed-price contract

Why would you want a fixed-price contract? Because you have a fixed budget. And in that fixed budget, you’re looking to achieve the Trifecta of Software Development:

You want to know how long the work will take, how much it will cost, and what features you will get.

Here’s the rub, though: establishing those 3 variables often takes more time than the development itself. Especially if you want to be certain of what you've established.

3. Fixed price = fixed plan?

The problem with fixed-price software contracts is the implication that a fixed price means a fixed scope. You’re assuming that there will be no changes in the plan of development.

Then, inevitably, the plan changes:

                     
• You look at the software mid-development and come up with great new suggestions for further work.
                     
• End users start sending in feedback and you’re starting to find out what they really want.
                     
• The market changes, forcing you to adapt to its needs. Or, in the case of internal tools, your company processes might change during development.
                     
• Your business model changes.
                     
• A third-party piece of software that your program depends on changes.
                     

Any of the above reasons may force you to rethink your plan. And when changes do happen, a change request must be issued.

The way Krzysztof paints them, change requests can be a major blocker. Mostly because they enforce a rigid scope that makes it difficult to implement any new and valuable ideas.

Any change in scope impacts the budget, which makes it necessary to renegotiate the whole deal. Sales needs to get involved, asking the client, “This change will take another five days. Do you accept?”

Think back to how long it takes to make a development budget decision in your organization. Until the decision is made and acceptance is granted, the developers can’t get to work on the feature.

And of course, more changes means more change requests means more time spent negotiating—and less time spent developing.

4. You can’t always know what you want

I’m not saying you can’t always get what you want, because The Rolling Stones have already covered that:   

But their next line is even more important: it’s all about getting what you need.

And that leads us to the number one fixed-price sin. You assume what you want is exactly what you need, or what your market and users need.

But then it turns out some features may be nearly impossible to create according to the specs due to unpredicted complications. Other features need to be expanded to be useful at all. You either go out of budget—or stay in it and get an unusable product.

Establishing absolutely all requirements from the very beginning is dangerous, because if you forget something—you will run out of budget and run out of time.

In reality, very often at the beginning of the development process you have a very concrete budget and a very vague idea of what you’re creating. The best way to refine that idea is through feedback.

With a fixed-price contract, the feedback cycle is much longer, e.g. you might only provide feedback after 2–3 months of work. Then you shift back to fixed-price negotiations for the next part and code for another 2–3 months. Estimating those fixed-price chunks takes a lot of work, and a lot of time spent negotiating. It could slow you down.

So if you really care about getting results on time, fixed-price probably isn’t the way to go.

Time-and-materials software development contracts: the alternative to fixed-price

So you could take the fixed-scope “Waterfall” approach, plan everything, then outsource the work in a “set-and-forget” fashion.

Or you could get started right away with a dedicated development team and create the vision together as you go.

That’s when a time-and-materials contract could suit you better.

1. What is a time-and-materials contract?

Under a time-and-materials contract, you pay for the work and the expertise of the development team, which you can direct in any way you desire.

A time-and-materials cooperation is based on a general scope and time estimates in the form of a roadmap. It doesn’t have a rigid end date and a “set in stone” scope. That means you can scale development up and down or terminate the cooperation when you see fit. The notice period is typically from the moment of decision until the last day of the following month.

2. The benefits of a time-and-materials contract

                     
• Changes aren’t a problem.
                     

With time-and-materials, changes simply move other items down in the backlog. And since the cooperation is open-ended, you can always say, “What we have is enough, let’s take a month to finish off the project and we will have a good enough MVP.”

                     
• You start developing right away.
                     

Instead of talking about what to build, you start building. You see the first results faster.

                     
• You can get your product to potential end users faster and validate its value.
                     

Timing is everything.

                     
• You can see how much work you can get done.
                     

More importantly, you can estimate it within a specific amount of time or within a certain budget.

                     
• You reduce the risk of “overdesigning” the product.
                     

Instead of planning all of its elements in advance, you can go through successive iterations until you arrive at an MVP that you can validate. It’s much easier to iterate on something you can interact with than to modify a 100-page specifications document.

                     
• With each iteration, you can give the development team concrete feedback.
                     

You collect the feedback based on actual software you’ve interacted with.

                     
• You’re flexible.
                     

With time-and-materials, it’s much easier to scale your team up (to develop faster) or scale down (to save money).

                     
• You also have more control over what to prioritize.
                     

You can push out features that will start bringing you revenue first, or the ones that are key to the end user, or the ones that will be difficult to implement. You decide.

The obvious reservation regarding time-and-materials is that the project might go over budget. But when you focus primarily on the business value of each feature, then quite often you actually finish the work faster. You might only be a few Sprints into development and already the result is a worthwhile MVP that you can show to both end users and investors.

Another counterpoint might be that if you go the fixed-price route, you can design the software from top to bottom before you spend a dime on development. That’s all true, but by spending so much time on planning you still risk complications down the line due to changing market conditions (and as we’ve established, change requests are hell).

With time-and-materials, you could already have the first working features after a week, you can provide rapid and relevant feedback, then switch gears and correct course as needed.

So do you want to spend two weeks talking about what you want to build, or start building and testing to see how much you can get done and how it fits your vision?

Fixed-price vs. time-and-materials: establishing the requirements

The main challenge of fixed-price contracts is that you must have answers to all potential questions before development begins. Usually those answers come in the form of a long document containing precise development specifications.

This document takes a lot of work to compile. It takes a long time to read and process. Anything that the document missed may impact the actual scope of work, meaning that the project could still go over budget.

Also, preparing the document in advance robs you of the opportunity to consult with your hired developers. Are the technical solutions proposed in the document feasible? Are they the most efficient? Are some features overkill? You need to answer those questions yourself, and be sure of your answers, if you want to get the results within your fixed price.

So if you’re looking for a fixed price, you also need a precisely defined scope. It basically forces you into a Waterfall way of thinking: “set-and-forget and let’s see what we get in a few months.”

Time-and-materials allows you to take a much more Agile approach. But that doesn’t mean you go in blind.

Instead of establishing requirements for the whole project, you start by planning just the first week or two. Instead of doing it alone, you do it along with your outsourcing partner, consulting with them on the feasibility of each feature.

Then, through refinements and planning, you arrive at a short-term game plan that’s constantly evolving. Every step of the way you make improvements to maximize the business value you gain.

It’s not about lines of code; it’s about business value

So you’ve decided on a time-and-materials contract that buys you a set number of development and testing hours. In effect, you have exchanged your cash budget for a “labor budget.” What do you spend it on?

Keep in mind that an average initial backlog can include 200–300 positions. How can you decide what to do first?

A great way to start is through business value estimation. Instead of looking at “features delivered over time,” you try to determine how much value each feature will bring your business once it’s released.

Depending on your business, your BV might be shaped by a number of factors such as:

                     
• potential revenue,
                     
• conversion rate,
                     
• impact on the number of sign-ups,
                     
• in-app purchases,
                     
• etc.
                   

To put all the factors together, you can assume an arbitrary business value currency, e.g. 1 BV. Or 1 golden coin. Or 1 golden cow. But we’ll use 1 BV in this example.

Then you can use BV estimation to establish backlog priorities. For example, let’s say that you decide feature A is worth 100 BV to you while feature B is worth 50 BV. However, feature A will take 10 hours to develop while feature B will take 1 hour. You know what to prioritize right away.

(Of course, to assign realistic business values you should know your market well to realize the BV of each feature. That’s the hard part. If you don’t know the market, the BV you assign might not reflect reality.)

BV is useful for startups who have exciting plans for lots of improvements but don’t know what will actually make their app more useful. Instead of adding bells and whistles, you can add things that will satisfy your target’s needs and help you monetize.

For example, you could rebuild your user panel to make it “more modern”—but your users usually won’t care. At least not enough to affect your bottom line. Alternatively, you could add a new payment system to your app that supports different currencies. The BV impact of the latter is clear.

That’s why, in working with a software outsourcing company, you shouldn’t look at how much code was provided in a given period of time. Instead, focus on the business value of the code delivered. A competent Product Owner will know your product environment well enough to help you establish BV-heavy features and expedite their release.

Time-and-materials: how to do it right

                     
• Understand that you can stop as early or as late as you want.
                   

The advantage of time-and-materials is the flexibility you get with it. If the results you’re seeing are not in line with your expectations, or if your financial situation changes, you can cut your losses and pull out.

                     
• Be transparent and engaged.
                   

In an ideal T&M partnership, both sides are engaged in the development process. Only you, the client, can verify and establish priorities. Consequently, T&M is not the way to go for those who want to “set-and-forget.”

                     
• Trust your partner—but verify the time worked.
                   

Time-and-materials can feel like a dangerous solution. After all, you trust your software partner with control over the scope of development. Thus, you have to trust them they are using the time effectively. A great way to keep that trust is to work with a partner that uses time-tracking software. With direct access to the software house’s intranet, you can be sure that the developers’ time—and your money—are being spent well.

                     
• Don’t get too flexible.
                   

Knowing that the developers will implement anything you desire, you may find yourself getting too ambitious. If the development team isn’t assertive and you have no filter, your backlog may fill up with tons of suggestions for superfluous features. Instead, think “simplicity is king.” Focus on the features bringing the maximum business value—a good Product Owner will help you identify those in a flash.

                     
• Keep a keen eye on the motivation of the developers.
                   

If you see signs of dropping morale, report your concerns to the Scrum Master. It is their responsibility to make sure work is progressing smoothly and team spirits are high.

Final thoughts

You may be thinking that this article was a little bit biased. Time-and-materials contracts seem to be the clear winner. But that’s just because we believe in most software projects and in most situations, they really are superior.

A software product is different than a car or a house. Physical construction leaves little room for change and improvisation. With code, on the other hand, you can always pivot.

That’s why the best approach is to start small (but not slow!), create a first iteration, then make changes as you go. Time-and-materials grants you the flexibility to do so.

But this flexibility requires trust, which is why software houses like us are eager to demonstrate their expertise through code reviews and UX audits. Once trust is established, everything becomes easier going forward.

If you’re thinking about software contracts and the intricacies of outsourcing, maybe you’d like to take a look at our C-level guide to software development nearshoring, or better yet, reach out to us directly?