April 11th, 2024, posted in learning
by Adelina
The idea of a fixed-price web development project can sound appealing. It gives the impression of a predictable project timeline, with no surprises and extra expenses. Pay upfront and wait for the project to be done and to see the final app in front of you.
Making a web development project fixed-price can be quite tricky, though. To reach that price, the project scope needs to be complete, final, covering the entire scope of work. Which, at first glance, doesn’t sound like much - but in web development, it’s not easy to cover everything before you actually start.
When we begin a new web development project, we do the entire design, approve it (which also means approving all features and user flows), and then we write user stories which will then be used as a reference for development estimates. But that’s your keyword - estimates.
Web developers will use their previous experience and general knowledge to estimate how long it would take to code a certain app. But that doesn’t account for unexpected events such as server issues, downtimes, API issues, lengthy software updates that can’t be postponed, bugs that are hard to fix, or even the clients changing their minds about certain features mid-development.
In other words, coding a software product can be unpredictable. Estimates can account for that, but they can’t predict everything. And it’s not always the development team’s fault - some of these unexpected events, as we pointed out, are external factors.
Not to mention the human, subjective aspect of things: the final design and the first live rendition of an app can come months apart. What seemed like a great feature in the design can seem convoluted or unnecessary in the live app. Which can lead to a derailment of the initial project scope, so the developers can make changes - a.k.a, additional development hours.
So in this article, we’re going to talk about why fixed-price projects don’t always work, so you can make the right decision for your software projects.
How do software development companies scope out a new project?
To fully understand how fixed-price projects come about, we need to explain how a software development company like ours scopes out a project. Since that scope will determine the budget and duration of the entire project.
Scoping out a new project can happen in a multitude of ways, depending on what the clients bring to the table. The biggest difference is the presence or lack of a final design, and/or willingness to take the time to build it first, in case there isn’t one.
When the project comes with a design already
This is one of the happier scenarios where the most important chunk of the product discovery process is already done. This is a situation where a client worked with one or more designers to map out the look and feel of the app, but they want to work with a dedicated team on the development part.
At this point, we would hold meetings to understand the project, your business and the design you’re providing. After which we’d write user stories based on those designs, and our senior developers would estimate how many hours each task would take to code.
All of this data is gathered and we make a total of the estimated hours, plus other things that go into a software development project: project management, testing and bug fixing, and technical supervision.
The biggest advantage of being in this scenario is that the developers will know exactly what they need to code, what it all looks like and how all pages and features will work together.
When the project doesn’t come with a design
In this scenario, we’d have to spend an extra month or two (depending on the project size) doing the entire product discovery process. This means sitting down with the clients and having productive chats about what they’re looking for, what the app should do, how their business works, and what kind of users their app should have. These details usually lead to rough estimates for design work, as we often decide exactly what kind of pages and features will go into the app.
Once we get all the information we need, we get down to business. We go straight into designing the app, while giving constant updates to the clients and ensuring we’re not missing any pages or features. After the design is done, the clients review it and we implement their feedback. Once everything is approved, we write user stories based on the designs. From here onwards, the process is the same as we described earlier.
Now, this situation is how we normally do this. This is based on our design-driven approach to software development, and we’ve found that it works much better than jumping into development. Doing that isn’t impossible, but it can lead to missing out on features, difficulty putting things together as developers only have a general idea on what the app should do, and the developers being forced to do design work.
In other words, going in without a design means accepting the risk of having inaccurate development estimates. The project will most likely end up taking longer and costing more money, to account for things that are missing in the first app iterations.
When the project comes with a design that needs updates
Here is a middle ground for the 2 cases we presented just now: some of the projects we work on are existing apps which need redesigns. This can mean anything from a complete visual overhaul to just small improvements. Most of the time, when we redesign an app, we improve its existing look and user flows based on user feedback. In other words, it’s rarely one of those 2 extremes.
In this situation, we’d start with a month or more (again, depending on project size; this can be way less) of design work, the duration of which is usually estimated after a few discussions with the app stakeholders. We use those discussions to settle on specific features and redesign directions for said project. In other words, we decide on what to redesign.
Once the new design is done and approved by the app stakeholders, we head into user stories and estimates, just like the other situations.
In conclusion, the biggest difference between these 3 situations is usually how much design work needs to be done. More design work means more hours, but it also means more accurate development estimates in the end.
What is a fixed-price project?
The concept of a fixed-price project starts with the premise of a software project that has been very accurately scoped out. These scopes would be turned into estimates of work hours, which would be put together to give a final time frame, and thus, price.
This not only gives a very specific price to the project that could be paid on the spot, but also gives a very specific time frame in which the project will be complete. And business people love hearing specific dates - it helps plan out your activities, you know when to let customers know that you’re launching something, and it gives you something to look forward to.
But this method starts off with a very optimistic point of view. Asking for a fixed price in software development means asking a development team to play a dangerous guessing game of “how long could this take?”. While knowing that a development process can always get interrupted by confusing bugs, missing features that weren’t scoped out in the beginning, technical issues, accidents (like data loss, for instance), and so on.
Of course, you can account for these risks and add to the project budget at the beginning. A margin of error, if you may. But there’s still a risk you won’t set aside enough, and you’ll still spend extra. Which goes against the idea of a fixed-price project.
Here’s a quick list of pros and cons:
Pros
➡️ You’ll know exactly how much you’ll need to pay for your software project, which helps with business budgeting.
➡️ You’ll know when to expect the app to be launched, most likely by a very specific date.
➡️ Work stops when the money runs out, so you won’t get randomly taxed extra unless you ask for that.
Cons
➡️ It’s not guaranteed that the project scope was done 100% accurately. You can’t predict every single thing that can go into an app before you actually start.
➡️ It leaves little space for a margin of error. Bugs always show up in code and they’re not always quick fixes. Plus, you can’t account for every single variable before you even start.
➡️ It can put pressure on a development team to work faster, which can lead to a sloppy end product.
So what’s the alternative to a fixed-price project?
The most common software development methodology, which we also used, is called Agile. The basis of Agile is splitting development work into stages called sprints. This helps organize tasks in a logical way, it helps prioritize them and keep track of what’s been done.
With Agile, development teams can scope their coding work by going sprint to sprint. This way, smaller chunks of work will need to be estimated, and it’s going to happen gradually, so some of the work will be done already when estimating new tasks.
This way, cost-wise, a project can be split into stages, which means gradual smaller payments. The clients pay exactly for what kind of work is done, and they’re always included in the conversation of what that work is and why it takes the time it does. They can ask for more cost-efficient solutions or they can exclude certain things that cost too much.
By doing so, the overall cost of the project won’t vary too much, the clients will be able to pay over time instead of a big payment at the start, and they have control over how much is spent on exactly what. This might be just as unpredictable, but a project wouldn’t start with a very specific cost but end up going over-budget. You might still go over a certain budget, but you’ll know exactly why.
In conclusion, starting off a project with a fixed price can be very tricky and leaves a lot of room for unexpected extra costs. As hard as developers work on giving estimates, they can’t think of every single risk which can add to that. And software development, like it or not, can be pretty unpredictable.
Looking to start off a non fixed-price software development project? You’ve come to the right place. Contact us and let’s discuss what we can build together.
