This is a second post in our "Basics of Custom Software Projects" series.

I had this client conversation recently when I heard a bit of frustration about pricing software projects.
When they talked to different agencies, each one either offered a different type of contract or even refused to give a quote. They said it's too difficult.

That's a bit of a problem, especially if you need to check if the project fits inside your budget.
It's easy with off-the-shelf solutions. They have a price tag attached to them, that lets you easily compare different options and assess the return on investment.

But unlike off-the-shelf solutions, custom software is well... custom.

Building software brings a lot of challenges. What appears simple when you look at the user interface can contain a lot of complex mechanisms under the hood. A simple button that adds a new contact to a CRM can trigger multiple additional operations - filling the contact with additional information from other sources, updating sales performance reports, sending e-mail notifications to supervisors... whatever you imagine. And on top of that storing the contact information itself.

The larger the project is, the more complex it becomes. On top of building new features, development teams need to also verify if what they've built doesn't affect the features that were already there. Sometimes even the slightest change can require changes in other parts of the software.

Because of the complexity, estimating the amount of work needed for a certain project can be extremely difficult. As a rule of thumb, developers are really bad at that. The more experienced ones often add a huge buffer for all things that can go wrong. Some will refuse to give an estimate for anything before doing a lengthy research.

That's the tricky part of custom software development. It doesn't however give an answer to the most important question - how much am I going to pay?

Three Common Ways of Pricing Custom Software Projects

Even though it's a lot of hassle, custom software projects need to be priced.
There are three common types of contracts for such projects. As there are a lot of unknowns when it comes to the amount of work needed, each of them tries to mitigate risks in its own way.

Let's take a look at them.


This contract type is quite simple - agency does the work for you, you pay for their time.
With hourly contracts you agree on a certain hourly rate, often with a monthly cap that will help you budget this work. Then, you can get down to planning the project and handing over detailed requirements to the developers.

This kind of arrangement is generally very flexible, so you don't need to prepare all the details in advance. If something's not clear in the requirements, you can always clarify them on the go. If you need to make changes in what was already built, that's no problem either. There's no fixed price contract that's holding you - you'll just pay for additional hours.

It also seems to be the most fair way of paying for the development work - if it turns out that there's less work than originally anticipated, you'll pay less. If the project turns out to be more complex, you'll just pay for the real amount of work.

The tricky thing with charging hourly is that it's impossible to know the total price in advance. You can approximate that yourself once the developers work on your project for a while. Seeing how quickly the work progresses often allows to estimate the total cost.
Still, you'll never know the total price until the project is finished.

Based on our experiences, we can tell that this kind of contract works well for long-term projects that have (at least a bit) flexible budgets. Such projects give enough time to find out how to approximate cost of its features.
On the other hand, if your budget is tight it may be difficult to run it with such cost uncertainty.

Fixed Price

The total opposite of hourly are fixed price contracts.
They promise a certain price for the whole project.

In order to start such project you need to first precisely define how the software should work. The requirements need to be detailed enough to let the agency understand how exactly the software should work. You'll usually need to spend some time with them to clarify anything that's unclear in the requirements. With that the agency will be able to give you a quote based on the estimated amount of work.

What's good for a lot of people in fixed price contracts is that you'll know the price in advance. It will often come with an ETA for the whole project. Agencies need to estimate the time anyway, since they pay its developers per hour or per month of work. What appears to be another advantage is that if the work takes longer than the agency estimated, you won't have to pay extra. They may be however tempted to finish the project quick and dirty, which will make it more difficult to maintain it in the future. It's common for agencies that agree for this kind of contract to increase the price a bit, just to account for such situations.

Problems with fixed price contracts start when you need to make any change in the requirements. Even the slightest change can have a huge impact on the total amount of work that needs to be done. Sometimes, you'll be able to renegotiate the contract and make desired changes. At other times, you may need to wait for the agency to finish the original contract and pay extra for the changes.

We haven't really seen this kind of contract to work well for anything else than tiny projects with a tight budget. The fixed price is fixed as long as the requirements are. Although it may appear counterintuitive, requirements in software projects tend to change a lot. That said, if you're considering ordering larger project for a "fixed price", be prepared to pay a lot on top of the original price.

Fixed Price Per Feature

And finally the kind of contract that's in between hourly and fixed price.

As difficult as it is to plan a large project in advance, it's usually possible to a good planning when focused on single part of the project (that is on set of features).

Similarly to an hourly contract, it involves recurring planning sessions.
During these sessions, together with developers you clarify in details how a subset of features should work.
Based on that, they prepare a cost estimate for just this set of features. Ideally, the features that are under consideration shouldn't take more than a week or two to build. This ensures the estimate to be more accurate.
Then, they can build these features and bring them to you for review. Once a set of features is finished, you can repeat the process and plan the following one in detail.

Although this kind of contract doesn't clarify the price for the whole project, it gives a better base for estimating it. Especially at the early stages on the project, when you don't know yet how quickly the work progresses. The agency still makes guesses, but they're smaller guesses. This means they don't need to add huge buffers to account for unexpected changes.
It also gives you the flexibility that the fixed price contracts lack. If you need to make a change in requirements for a feature that wasn't built yet, the contract doesn't prevent you from doing so. If you need to make changes in a feature that's currently in progress, it's still easier to renegotiate a week-long contract than a year-long one.

What may appear as a disadvantage, especially compared to hourly contracts, is the amount of time that you need to spend once in a while on planning sessions. While they're time consuming, they're a great opportunity to think in detail about how the custom software should work. To make the best out of per feature contracts, you also need to spend some time to define priorities and order in which you want to build features.

Fixed price per feature is the type of contract that we're currently experimenting with at Upside. We've noticed that a lot of our clients who paid hourly rates ended up trying to assess the total amount of money needed to build a certain feature anyway. Paying per feature adds a bit more clarity to that.

This kind of contract, just like hourly, works well in longer projects. Unlike hourly, it shows more predictability at the early stages of a project. And since it's similar in its nature to hourly contracts, its quite easy to switch between them once you get a sense of how the work progresses.

Which Type of Contract Should I Choose?

The kind of contract that's best suited for you depends a lot on your project and your preferred way of managing uncertainty.

From our own experiences, we'd advice you to be extremely careful with fixed price contracts. Although they may seem to deliver software at predictable price, they can easily add a lot of hidden costs.

In the past we've used to work mostly with hourly contracts. They work fine in general, especially due to their flexibility. If you feel the need to know the price in advance, you can give the "per feature" contract a try. They'll give you information that's helpful with budgeting, while also pushing you to plan the project properly.

This is the first article in our series on basics of running software projects. We'll publish a new one every week until we run out of topics.
If you enjoyed it and would love to learn more about working with developers and software agencies, sign up to our newsletter.
We'll send you an email once we publish a new post.