Table of Contents
The usual way to determine the actual budget for the development of a software project is getting the price from different companies and comparing them. However, it’s also the case that once you receive those ETAs, the range is so different that you can hardly determine which one is correct and what company to go forward with.
Based on the experience of around 10 years of software development as well as by analyzing the estimations kindly provided by our partners, we have defined the most important items you need to pay attention to when comparing several estimations.
The article will be useful for those potential software owners that already received the budget and duration estimations from several development companies and are looking for ways to compare them and pick the right team. But, if you are also looking into the insights of what the software budget might be dependent on, you will also find the results of our research useful. Development teams that are looking to optimize their estimations can benefit from this article too, since they will find here the comparison and general statistics of ETAs from their competitors.
Ensure that the teams are estimating the same scope
The most important thing is to make sure that the development teams are estimating the same scope of work. The ETA depends on the level of functionality development team needs to provide and hence the time the dev team will spend delivering it. In order to achieve understanding of the same scope someone needs to list the functionality and limitations of that functionality. You can do it yourself, however, you might not necessarily know the limitations that you need to provide for an estimation in order to make sure the team estimates just what you need.
Example: Registration
Possible variations of Registration scope that might affect the ETA:
- Variant A: Standard registration with the form by indicating email and password.
- Variant B: Registration with social networks like Facebook, Google+ or Linkedin
- Variant C: Registration with a phone number with verification of that phone number
In all three cases the estimated time to develop these three different flows will differ with Variant A being the cheapest . Variant B would depend on the number of social networks you will have. Variant C would be one of the most expensive, taking into consideration the additional cost to pay for sending each SMS.
Good development team makes the list of functionality by themselves. Why am I saying “a good development team” does this? Because having a Business Analytic to write that functionality list with limitations takes time and money and not all development companies are ready to invest their time and money into writing down that scope without actually knowing the project will be awarded to them.
Another benefit of having that list done is because this allows to avoid the risk of missed functionality at later stages and because it guarantees you won’t be charged for additions. This also ensures the development team understands the concept and problems that your software is resolving.
Conclusions:
- The more accurate ETA is from those teams that provide the list of functionality they are estimating for starters and at most the limitations that each functionality includes because that team did their homework and is more aware of the scope and potential additional costs. Such ETAs will generally give bigger budgets because those teams indeed estimate the full scope instead of giving you a relative (more or less accurate) budget.
- If you have the list, send it to all teams and get their confirmation that all features from the list are included. This way you can ensure that when comparing the budgets, you are comparing the budgets of the same scope.
Ensure that all roles that are required for development are included into the budget
Very often development teams would give you the price only for the actual development, omitting such important aspects as:
- Project Management (leading the dev team)
- Business analysis (scoping of the functionality)
- Testing (ensuring the quality of code)
- Design (which allows to save around 25% of costs)
- Admin and Devops work
Naturally, the price would be more attractive if you do not include those roles, since PM work takes around 5-20% of the project time, testing from 10 to 40%, depending on whether you have automated testing or not, design may take 3-10%, and admin’s work additional 3-10% based on how server intensive your application is.
The percentage is based on the actual stats and the work of our team as well as on general market research of ETAs made by our team.
The potential risk here is that you will have to compensate for the absence of those roles by doing this work by yourself (and a regular client won’t necessarily do this work correctly).
Example: no Testers work is included into estimation
As a result, you will have to test the application all by yourself and this results in a big number of missed bugs, bad reviews from the end users, and app’s failure on the market. Besides, this also affects the costs. The bug identified during the development and fixed at this stage is around 200% cheaper to fix vs. its post-release fix.
Not having a PM would require your full involvement in the process, including daily calls with the team that might not even be in your time zone if you’re outsourcing. Lack of coordination in the development flow between a developer, a designer and PM is a potential loss of money on the downtime of developers which would cost you quite a penny. PM from a dev team ensures that all team members have work and that the time is spent effectively.
Not having a BA results in a potential loss of functionality or even finding the features developed not the way they were intended to be developed which would result in additions to budget due to the change of already developed functionality.
Conclusions:
Ensure that, apart of development itself, the ETAs of all teams include the work of the following specialists with the indicated proportions:
- PM – 5-20% of total development time
- BA – around 8-10% of total development time
- Testing – 10 to 40% depending on whether you have automated testing or not
- Design – around 3-5%
- Admin’s work – roughly 3-10%
In case some roles are not included or included in smaller or bigger proportions, ask WHY?
Also ask how many developers will be working on the project. More developers there are, the more expensive it becomes but at the same time you get the solution developed faster.
Ensure that development teams use the same technologies
Another important thing that affects the resulting budget is the technology stack that team selects for the project.
Example: You want to develop a mobile application
- Variant A: native mobile apps
- Variant B: cross platform solution such as Xamarin or React.js
Variant A is generally more expensive because it involves a separate developer for Android app and a separate coder for iOS. However, cross platform technology allows the development of a single backend code and its further complication to Android and iOS apps, thus saving development time and, consequentially, the total cost.
The technology stack is very often not the result of a choice but a result of the requirements of your software. Not everything can be developed with different tech stacks. Besides, some provide better quality, others do it worse and can result in additional costs spent on maintenance of the apps later.
Conclusions:
- Ensure the received ETAs of budget have the same or similar tech stack
- Ensure that when you select the stack, it gives you the required quality-cost
Ensure that development companies provide a maintainable solution
At early stages clients forget that once they spend their time and money to develop the applications, there’s also a big deal of effort they have to spend to maintain the ready software. And here’s where you need to make sure that the team will provide you with the code that you can actually maintain and extend, if necessary, to include new features. How to ensure this? Make sure the ETA of development teams include:
- Documentation of the code – to ensure that, if you decide to switch the development team, the new team will have the well-documented code to understand how it works
- Code review – to ensure that someone looks after the code and there’s no risk of spaghetti code
- Architect role – to ensure that general architecture of the app will be developed the way that it can be extended later
Example: You developed the app and are ready to release it but you are swamped with a big number of bugs and their fixing takes ages
Variant A: Team never documented the code and substituted team members within their own development team and new team members take ages to make sure that fixing one bug doesn’t cause another bug – this is potential additional costs to integrate a new team member or to spend huge amounts of money to stabilize the app
Variant B: The code review was never done and this resulted in a huge tech debt. As a result, adding new features makes the whole code unstable and brings lots of bugs. The tech debt costs might be huge and can not even be estimated because they depend on how bad the situation is.
Conclusions:
- Check if the estimation includes documentation (as a swagger, test cases, text checklists, code commenting, etc), code review or at least architect role to make sure that you will get a maintainable viable code
Communication
Very often teams include communication into their budget estimations. It’s important that communication is kept within reasonable limitations. Based on our own statistics as well as ETAs we received from our partners, communication usually takes up to 20% of the development time, sometimes less. The more detailed the specifications are, the less communication you need. Skipping this entirely means that the team will be disoriented with a lot of misunderstandings between you and the team,or between themselves. In the end it might lead to additional costs for redevelopment of the ready functionality, bad code, and who knows what other problems. The communication should at least include:
- Time for daily standups to guarantee team’s daily coordination and status check
- Planning communication
- Functionality refinement communication
- Communication as a result of reporting the ready scope
- Communication for optimization of the development flow
Conclusions:
- Ensure the provided ETA includes time reserved for communication inside the team and with you
- Ensure the communication time is kept within 20% out of total project hours
Ensure the team has expertise
How can it be that different development companies give estimations with such a huge gap? This depends on whether the team has expertise in the industry of the project you are trying to develop. If the team is doing such a project for the first time, the risk that they underestimate or overestimate the project is very huge and for you this means either paying for additions, or paying for developers learning how to do their work. Of course you can never be 100% sure that the team has expertise even if they say they do but here are a couple of things that will help you to ensure they do have the experience in building similar solutions:
- They have the case studies or actual live application similar to your project in their portfolio. This is very easy to verify by looking at their portfolio on a website or requesting links directly from your contact person.
- Another way to verify this would be to also check the reviews from their customers. Such platforms as Clutch or Goodfirms, apart of giving the reviews about the work of the team from the actual customers which can be useful by itself, also give at least basic description of the projects for which they are getting their reviews. And, if the descriptions of those projects are at least somehow alike that of your projects, it’s safe to assume they have the expertise.
- Expertise in technologies and working with the 3rd party services are not less important. See if the projects they developed used some or all of the services that your future app will have.
Generally, the team that has expertise would give you more accurate estimation (versus cheaper one) cause they know the potential risks and problems they might face during the development and this way ensure you that there’s no overestimation or underestimation
Conclusions:
- Check portfolio of the team for similar projects
- Check the review platforms to see if the team has feedback from real customers with the description of a project similar to yours
Wrapping Up
When comparing or asking for budget always remember that you aim for the ACCURATE budget rather than the cheapest budget. I know, cheaper is always more attractive but no development team is looking to under- or overestimate because this is just not in their interest, especially if you are talking to the company with a good review history and solid reputation on the market. They will still get the money they spend for the development, whether it is by charging you for additions or writing spaghetti code to speed up the development and close the project that is not profitable for them. But it’s you who needs to manage the costs and the cash flow and it is also you who will end up with either a realistic forecast, or a budget just good to your eye.
