How to price software development for your company
How to price software development is a complex proposition. There are a number of factors to consider. If it is done well, it can set your business on a path for success. If it is done poorly, it can have a negative impact that is not obvious until it is potentially too late.
Before founding Codebots, I spent many years building up a software development company and I learnt many lessons; how to price software development in an Agile world being one of them.
Most, if not all, customers want an Agile project. The idea of releasing often and learning from the end user is appealing. This can increase the chances of a successful product. But customers also want the certainty of a waterfall project. They want to know how much the project is going to cost, this is especially true for tender processes.
This is a conundrum, but it is ultimately at the heart of how to price software development for your company.
“Software engineers can easily fall into the trap of agreeing to deliver software to solve an unclear business problem, with unclear requirements, within a negotiated time and cost, that not only meets user and customer needs, but also the needs of support teams. There are too many variables to be certain and this is compounded when you add additional variability like the delivery team’s own experience and capability. This means that we have to become comfortable with uncertainty. Where uncertainty is high, we can either embrace it and accept the implications, or try to remove the uncertainty with the corresponding implications.” Clifford Foster, Partner at Platform Engineering, Deloitte Consulting
Throughout this article we are going to examine a number of key issues that contribute to pricing and attempt to answer some hard questions. But before we get underway, I want to draw your attention to a very important concept … risk. Risk is inherent in everything we do. I would go as far to say that it is universally true like the laws of nature. So, keeping that in the back of your mind is very important as who is taking on the risk for a software project will have a big impact on pricing.
The following questions will be addressed below followed by a summary.
- How much to charge for your team?
- How do you charge for an Agile project?
- How do you quote for an Agile project?
- How do you quote when you are forced into a fixed price for an Agile project?
How much to charge for your team?
The simplest approach is to use the market rates in your location. If you don’t know what these are, it is usually pretty straight forward to find out. Ring up the competition and ask them if they have a charge sheet. Some may not give you an answer but you will find enough information to work it out.
Given the market rates, you will then need to decide where you want to position yourself. Do you go higher and offer a premium service, or do you go lower and try to win on costs. This is a classic business question.
However just following the herd like this and using market rates may not create a viable business as the end goal is to create profit. Broadly across all business types, a 20% profit margin or higher is considered good. Below 10% is getting low but some business types operate with these tight margins.
A good starting point to calculate the actual $ value of your team working on the project is to use the rule of thirds; one third to the employee for wages, one third for costs to the company, and one third to profit. An easy starting point for the ratio’s could be an even split:
employee : costs : profit
33.3% : 33.3% : 33.4%
So, if you pay your employee $50 hour (including superannuation, holidays, etc) then you charge them out to customers for $150 hour. You will need $50 hour to pay for company costs like equipment, running costs, and any non-billable staff. Finally, you will need to have a margin (some profit), which is the goal of a company so that it can reinvest in its own growth like R&D or expansions.
33.3% : 33.3% : 33.4%
$50 : $50 : $50
There are many downward pressures on the maximum price that can be charged. The most prominent is what the competitors are charging. If you are an established company, you may be able to command higher prices because people are willing to pay for more certainty in the quality of the project and the knowledge that your business will be there next week. But if you are a relatively new company and you are significantly more expensive, then you will simply price yourself out of the market. So, many companies will end up with different ratios and it depends on your circumstances. Maybe you could push your costs down and increase your margin like shown next. This looks better 😀
33.3% : 26.7% : 40%
$50 : $40 : $60
New software development companies usually have a better margin as they have not had to add in middle management employees which means they can keep costs down.
How do you charge for an Agile project?
The natural fit for pricing is to use Time and Materials (T&M) for Agile projects. T&M is a traditional approach to contracts whereby the customer pays the contractor for time spent on the project and any materials used for the project. This approach is good for when you cannot know all of the requirements of a project. This fits well with Agile as embracing change early is one of its key concepts.
Most T&M projects will be based on hours or days spent. We tried pricing based on weeks spent but ended up swapping back to days as we found it was a better level of granularity and created good transparency for the customer on how much time was being spent on the project. Some other software development companies use hours. Take a look at the table below, which shows how you can break your invoices down by the different roles involed within the team.
| Description | Quantity | Unit Price | Tax | Amount |
|---|---|---|---|---|
| Squad Lead | 30 | $150 hour | 10% | $4950 |
| Senior Software Developer | 30 | $150 hour | 10% | $4950 |
| Junior Software Developer | 20 | $50 hour | 10% | $1100 |
| DevOps | 10 | $100 hour | 10% | $1100 |
| UX Designer | 20 | $100 hour | 10% | $2200 |
| Solution Architect | 5 | $200 hour | 10% | $1100 |
Don’t over read into the unit prices above as these will vary based on your location, but I wanted to show how you can break down your invoices. In this case, we have broken it down by role and charged the customers for hours spent on the project.
How do you quote for an Agile project?
The next big thing to tackle for Agile projects is how to quote. When a customer comes through the front door and asks the question; how much will this cost? You will need to provide an answer. If you cannot provide a satisfactory answer the customer will simply move on to the next software development company. Deal lost … ouch!
A quote is an estimate and software estimations are notoriously difficult. Many of my previous articles on software estimations have reached rank #1 on Google. As you can see below, if you search for software estimations, we come up first. We also rank #1 for software estimates as well. Have a search yourself to confirm, we should be somewhere near the top (depending on your region).
The article 7 ways to estimate a software project is a must read. And importantly, there are ways to use different estimations depending on what stage of the sales cycle you are in. Most software development companies will have a number of stages and the key idea behind this approach is to address risk and uncover what the customer really needs. For example, at WorkingMouse, they generally use the following 3 stages:
- Brief - Echo back the customers problem and set some high-level goals.
- Scope - Unpack the problem further and define a solution based on the goals.
- Development - Go ahead and build but not too far into the future as the Agile philosophy is to release often and gain user feedback.
The brief stage is free but the customer pays for scope and development. By breaking scope and development into 2 stages it allows the customer to control the project and not commit to its entirety. This is not the secret source of WorkingMouse and many software development companies have something similar.
“The most important thing in scoping and estimating an Agile project is to remove as much risk as possible but leave room for the Agile process to work during development. Transparency and communication about the remaining risk and acceptance that the scope will change during development is key, especially with a client that does not have experience building an Agile project. The success of a fixed price (i.e. time) project depends on all stakeholders trusting each other and refining the scope along the way to ensure it delivers on its business objectives.” Matt Francis, CEO at WorkingMouse
How do you quote when you are forced into a fixed price for an Agile project?
There are simply situations that will come up where you are required to give a fixed price. Software development companies find this more as they move onto larger enterprises and government work that require a tender process. In this scenario a lot of the risk for the project is moved onto you, so tread carefully.
There are many risks in developing software and the further into the future you try to predict, the more they seem to compound. The cone of uncertainty (shown below) is a good picture of what happens.
When you are forced into a fixed price contract the cone of uncertainty must be taken into consideration. Different software development companies have different ways of approaching this (even though some do not realise it).
A traditional approach is to spend a lot of time scoping out the work so you know more precisely what is going to be built. This can make both sides comfortable as some of the risk has been removed but this is more waterfall than Agile. The other problem with this approach is who pays for the scoping? The customer wants to know how much it is going to cost but you will need to spend weeks, sometimes months, working out what the scope is so you can answer that question. An obvious answer is to ask the customer to pay for scoping but in a lot of circumstances that will not happen.
In practice, a lot of software development companies go ahead and sign the contract but have clauses around changes to scope. So that any time there is even a sniff of a change to scope, including scope discovery, the customer is served with a change request. Each request would need approval and would also increase the contract value. Besides being an admin nightmare, this can have a negative impact on customer relations as you will need to hold your hand out for every change.
Some software development companies are embracing a non-traditional approach where they are running Agile projects under a fixed price. This is only possible if both the customer and the company agree that the scope is not fixed. This means the project can be given a fixed amount of time, say 12 weeks, and therefore a fixed price can be determined. Then the software development company, under the direction of the product owner, applies Agile principles and releases often and gains user feedback.
This approach will not work in circumstances whereby the customer believes the scope is fixed, in low trust environments, or circumstances where there is not a strong product owner that can drive the direction of the project. If you do go ahead and attempt this scenario, it is always advisable to include a quote for a fixed scope alongside your proposal. In this way, the customer will have better education around the processes.
Summary
In this article we have looked at how to price software development for your company. We have discussed how much you should charge for your team using the rule of thirds as a starting point. We have covered the use of T&M as a natural alignment for Agile. We have looked at using a staged process of estimations and provided some links to other articles on estimation techniques. And finally we examined some different ways you could handle a situation where you are required to provide a fixed price.
Experienced practitioners know there are many risks when building a software application and that the best way to mitigate risk is to create certainty. When machines were introduced to manufacturing it revolutionised the industry and created more certainty on the production lines. An interesting thought is how can a codebot help with certainty? We know from our stats that a codebot writes on average around 93% of a software application. Could a codebot have a similar effect on your software projects? This question is worth thinking deeply about.
At Codebots, we will continue to apply science to these questions and innovate with new techniques and tools. We are not claiming to be a silver bullet as there will always be human factors to why software estimates are so hard, but you can sign-up today and start using a codebot to create more certainty in your projects.
Written by Eban Escott
Founder of Codebots
Dr Eban Escott received his Doctorate from UQ (2013) in Model-Driven Engineering and his Masters from QUT (2004) in Artificial Intelligence. He is an advocate of using models as first class artefacts in software engineering and creating not just technologies, but methodologies that enhance the quality of life for software engineers.
