No one likes to pay a lot of money when less money can be spent. When comes to the financial part of the project, it’s always a sensitive topic.
In this article, we will focus our attention on one of the most well-known models of budgeting – the Fixed Price model (and the other will be covered in upcoming articles.)
There are three major pricing options models available in the outsourcing business:
- Fixed Price
- Time & Material (aka T&M)
- Dedicated Team
What is a fixed price?
The fixed Price budgeting model for software development is when you have an exact sum of money that is estimated at the very beginning. This means that the total budget of the project development is known before the development actually starts and in some cases, this is a great option to go for.
While this might seem like a win-win situation for everyone, there are cases when Fixed Price isn’t the favorable option and we’ll cover those situations later in the article.
4 steps to take before the start of a project
Let’s walk through the steps, with you being the client and us being the developers.
First contact.
You approach a software development company with an idea of a project or more or less concrete tasks and share what you are expecting to get as a result and what are your business goals. The reason we need to hear about your business goals is that there are many technologies and many ways to do the same task, but they all have their weaknesses and strengths. To choose the right one, we need to know what your business needs. We can sign a Non-Disclosure Agreement (NDA) before you share any details with us. The more details you provide the more precise will be the quote.
Assessment.
The developers’ team together with the project manager gets to assess the tasks that are required. Sometimes basic things might turn out to be not so easy to implement and vice versa – some things that sound complicated can be easily integrated into the project using various APIs.
Estimation.
Once the tasks have been written out in tech-speak, the developers can estimate each of the tasks separately and the PM creates a file with stages and costs incurred.
Signing the contract.
At this point, you and the PM discuss the estimation (note that this isn’t a rough estimation that is usually done as the initial step, but a deeper one) and payment structures. For example, in the Fixed Price budget model, it’s traditional to do a down payment at the very beginning before the development starts and then at the milestones.
In the article about mobile app development cost, we have covered the process of estimation in more detail.
Key to Fixed Price Development
There is one main “secret ingredient” that’s not so secret really – for successful project development, you need clear and detailed technical specifications. Technical specification (or technical documentation) is a document that specifies various parts of the development.
For example, it can include (click the link to go to that specific place or simply scroll):
- General Description
- List of Actors
- User stories
- Supported platforms and devices
- Third-party services integration
- For further releases
- Use Cases
General description
General description gives an understanding to a person who isn’t familiar with your project a quick idea about the purposes of your app or e-commerce website, for example, and its business goals.
The main goal of the product is to build a mobile app that would daily and automatically congratulate a random person from the imported contact list with a current holiday. The application automatically gets the current holidays from the https://holidayapi.com/ website.
The project will consist of two components:
- Android native mobile application for users
- iOS native mobile application for users
The business goal of such an app is to integrate with major e-commerce platforms and simplify the process of remembering to congratulate someone on an important date and get a gift in time.
List of Actors
Actors in the given context are all users (including admins and super admins) who come into contact with your app or web project.
Describe their roles and what they can do. For example:
- User (aka End-User) – a person who would like to send and receive greetings via messages
- Admin – a person who is adding news and informational updates to the app to provide communication with the end-users
User stories
User stories are actions that can be performed by your users. For example, it can be logging into the app or sending a message.
Actions for admins are also described, for example, adding a user. In the beginning, you simply list all activities that users can do (without details.)
- As a user, I want to Sign In/Log in to get access to app functionality
- As a user, I want to add contacts to the congratulations list
- As a user, I want to start/pause automatic greetings
- As a user, I want to receive an invitation notification to read the congratulatory message
Supported platforms and devices
Write a list of platforms and devices you want your product to be available on. For example, iOS 14 or later. Here you can also specify screen orientation or web browser requirements if any.
- Operating systems supported: Android 11 or later / iOS 14 or later
- Screen orientation – portrait and landscape
Third-party services integration
Third-party services are great because they provide various functionality that doesn’t have to be written from scratch, which often saves time and money.
If you are planning to use any third-party services, you have to specify which ones you’re going to use, so that the developers working on your project would understand what kind of integrations they would have to take into account.
- Google Login API – service that allows implementing login option
- Holiday API – service that provides information on daily holidays based on the country
- Push notification – service for sending push notifications
For further releases
We usually advise starting with an MVP (Minimum Viable Product), which means your app or software gets the core features for the initial release, and then another functionality is added later.
This is done for several reasons. The main reason for MVP is to have the product out and about so you can start testing its market fit with real users. Another reason can be that you might have a low starting budget and the MVP will give you something to present to potential investors.
Having ideas of where you would like to take this product in the future gives your product architects and/or developers the chance to lay the foundation for those features at the beginning. For example, if you would like to add integration with social media or something else.
- Add useless fun advice for each holiday congratulations
- Share received congratulation and advice via social media
Use Cases
Now you describe the use cases in detail, including the preconditions that are required for the action to take place, how the action is triggered, and the main flow. It also describes the possible alternative flows.
Use Case #1
| Description | Login via email |
| Primary actor | User |
| Preconditions | The user is already registered in the app using the email The device is online and has an Internet connection |
| Design/Screen/Form | Screen_01 |
| Trigger | The user launches the application |
| Main flow | The user enters credentials: Email; Password; User clicks Login |
| PostConditions | The user logged into the App, lands on the Home page |
| Alternative flows | If credentials are wrong, then Alert is shown: Sorry, wrong credentials. Please try again. |
Along with the technical specification, another document is also prepared, which describes the deadlines, sets in the budget, and the milestones of the project. In the case of the Fixed Price budgets, all later changes can be done only in addition to these documents.
Side note: we use Agile project development which is a way to structure and prioritize tasks and allow flexibility in the sequence of the tasks. The flexibility here only relates to the processes, not the project scope, when we're talking about the Fixed Price development because the project scope is fixed, just as the price.
Pros and Cons of the Fixed Price: Comparative Table
| Fixed Price Advantages | Fixed Price Disadvantages |
|---|---|
| Fewer risks for you (even if the developers take longer to work out a feature, the total price remains the same.) | Preparation takes a while to finish because you need to clarify all the requirements and technologies from the very beginning. |
| Known price from the very start. | You can’t do any changes to the project’s scope without negatively affecting the existing tasks. * |
| Clarified expectations and requirements. |
*Additional features or tasks would require either moving the existing tasks out of the project scope or signing an additional contract for that specific feature or set of features and pay for them separately.
When to use and when to avoid Fixed Price?
Fixed price isn’t a one-fit-for-all type of budgeting. There are cases when it’s a great idea to use this model and there are also cases when this would be digging a hole for yourself.
When should you USE Fixed Price?
- Your project is small (up to 4 months of development time total) – anything longer than that would require more flexibility since it’s impossible to think of all possible scenarios and adjustments ahead of time (or it would be incredibly expensive and take forever.)
- You’re planning to do an MVP for market testing and pitching to investors. As we mentioned above, MVPs contain the main functionality and focus on the core business value rather than covering all the features you’d like to add. MVPs also allow doing proof of concept to understand whether your idea is going to fly at all.
- You are adding new features to an existing product and don’t need to build from the ground up. If this is a new project for our team, there has to be some time set apart for integration, but if we have been working with your product before, separate features can get a Fixed Price budget. That said, we would recommend going with the Time&Material option in this case because, as we mentioned before, some things might take longer, and some things might take less time. In the Fixed Price model, you’re paying a general sum, while in T&M you are paying for the hours worked.
- You have the detailed level design technical documentation already and therefore it’s easier to create a precise estimate.
- You don’t need much flexibility for the market fit because your product is very specific as it is.
Fixed Price model requires 50% (in some cases, 30% when the project is large) down payment before the start of development.
When should you AVOID Fixed Price and use Time&Material?
- You have a project that is longer than 4 months. While the MVP can be done via Fixed Price, it’s better to switch to monthly payments or a T&M structure after that to continue efficiently developing your project.
- You have an idea, but it’s not clearly defined yet and you’ll definitely need to play it by ear. In cases of required flexibility, it’s always better to go with Time&Material which offers wiggle room in development time but also in the priority and number of features of the product.
- You need to be flexible with a budget in general. Sometimes, it can be a month of work-work-work until the release and the project milestone, and then it’s a quieter time for development, with just a few things to work on.
Takeaway
Money. Always a tough topic to discuss but it is such a necessary one.
In this article, we’ve talked about the Fixed Price model of project budget, which is a great solution in some cases and not-so-great in others. If you still have some questions or suggestions, let us know and we’ll add the information to this article.
If you’re looking for a software development team, contact us or check out our portfolio.
Book a call with our experts
Feel free to drop us a message regarding your project – we’re eagerly looking forward to hearing from you!