It depends! 😬
Answering how much a project will cost often opens a big can of worms for any software provider. As people, we are so used to knowing how much something will cost that getting anything but a firm price doesn’t always feel right or make sense.
Why is buying software development services so different than off-the-shelf products? Well, every aspect of an off-the-shelf product is known so the price reflects that. Now when it comes to software development there are many unknowns and variables.
So let’s break down the main ways software projects are billed then.
Fixed Price, Fixed Scope
The standard waterfall method where you agree on a detailed set of requirements and price.
Time — Because the scope is fixed, the timeline might change depending on how smoothly the development goes
- Need to properly create requirements in advance
- The vendor owns risks — if the project goes over budget then vendor assumes the costs
- Fixed cost projects mean you know how much something will cost upfront.
- No flexibility in terms of features, changes, etc
- Will have to pay for creating specs in most cases
- The estimate could be conservative to ensure tasks are not over budget. Therefore, if tasks are done faster than originally estimated then you are paying more
- Quality might suffer as the vendor is trying to get everything done within budget
Time & Materials / Variable Price, Variable Scope
Another common approach where the vendor bills all the time worked on the project
Both costs and the timeline are constantly changing as you work more on the project.
- Scope creep. Because costs and time are flexible it’s easy to keep working without an end in sight
- Spending too much
- Pushing the delivery of the project to include more features
- The client assumes all risks
- Maximum flexibility
- Scope creep
- Easily to go over budget
Fixed Price, Variable Scope
In this approach, the client and vendor work together to create a fixed budget and timeline. They work together to complete as much work as possible within those 2 constraints.
- Scope — what will be worked and how much will get done varies.
- Vendor and Client share risks so the risk is reduced for each party
- Ensuring a suitable budget is established before the project begins
- Focusing on the wrong features can make the product feel unfinished
- The entire system doesn’t need to be detailed before agreeing on a price
- Fixed price means both parties are trying to make the budget work while getting the most amount of work completed
- Firm budget and deadline when development will stop
- If the team is efficient might get rewarded by finishing more features than anticipated
- Can change features and add new ones as long as it seems appropriate leading to a superior end product
- If the team is inefficient then might not get as many features as you hoped for
As you might have guessed — our preferred approach is the last one. Rather than trying to determine everything in advance, you do enough work to determine a responsible budget. From there, we work together with our clients to build the best application possible within their budget. This approach gives them flexibility in case changes need to be introduced, keeps both of us in line by putting budget and time constraints and mitigates risks by sharing risks.