How much will my app cost to make? This is one of the most popular requests in our day-to-day work. Unfortunately, software development is a service, not a product you can give a price tag right away.
Seems like an easy equation: time = money. Define time needed for development and you’ll get the price. But, it’s hard to estimate the time needed to complete something as big as software app. Someone should sit down and write a big list of tasks, TO-DOs, risks, required people and time needed for development.
That’s why when someone gives you a quote immediately or claims to have 90% accuracy, don’t buy it!
Estimation is a complex process. Moreover, final accuracy of the quote is largely dependent on you! So, how it works?
Required Inputs for Estimation
There are several basic ingredients required to make any estimation. The scope, risks, and technologies. The accuracy of any quote greatly depends on digitalization and completeness of those inputs.
This is a first and foremost ingredient required in every estimation. This is your idea, something you write down in our contact form, or describe in details during Skype call with our client manager.
No one knows your project better than you do and we can’t imagine it instead of you. That’s why your input on this stage is irreplaceable. The accuracy of the quote depends on efforts on this stage.
But do not be scared! We won’t ask anything that goes out of your competence. We’ll help you to crystallize the idea without getting into technological debris. We have client manager, business analyst, and software architect for this stuff. They will tweak and adapt your idea to technological standards and industry requirements.
Basic use cases, app’s functions, features and problems you want to solve - that’s all we need from you for a start.
Upon getting those answers we’ll make work breakdown structure, which divides the project into separate tasks. E.g. You Project = Function A + Function B + Feature C (module 1 + module 2).
The more detail we can get the better estimate we provide.
On average, we have three detail levels, depending on the amount of information provided by the client:
- Rough Estimation (up to 40% accuracy) – based on project goals, problems you want to solve and rough use cases you may have.
- Detailed Estimation (up to 70% accuracy) – based on detailed description of use cases and features you want to have in your app. Detailed estimation takes into account risks we may face during development.
- Pre-development Estimation (above 90% accuracy) – based on specifications of the project, which includes in-detail description of each use case, function, and integration.
Keep in mind that small projects or those with detailed inputs and design allow us to provide Detailed Estimation from the very beginning.
Risk is a general naming for all assumptions and constraints that may or may not affect the project. As we proceed from stage to stage, those assumptions convert into details and constraints are solved.
There are two kinds of risks we account during estimation: internal, and external.
Internal risks are associated with previous experience, uniqueness of technologies, and software solutions we’re going to integrate. The more experience in particular field we have, the more accurate we can estimate the project.
Let’s make it clear: having risks does not mean that we can’t create something. Risks just indicate the difficulty in accurate estimation (up to 70%) of particular tasks.
External risks cannot be predicted based on previous experience of our team. Usually, those risks are unique for every project. External risks are related to third-party API, legal issues, industry requirements, etc.
For example, our client wanted to make mass payments via PayPal and get in-detail breakdown on every transaction inside this particular mass payment. PayPal’s API by default refuses to provide a breakdown, thus, we had to dedicate an additional time to overcome this constraint.
In addition, there are organizational risks that may occur during development. Such risks are solved through transparent and professional communication with Project Manager.
Each tool has its purpose. Some tools are better suited for solving specific problems. Some technologies require more expensive specialists. That’s the reason why one technology stack can be cheaper than another. Frameworks, for instance, can save you a lot of time coding. Ready-made code solution does this trick too.
In most cases, the decision whether to choose certain technologies is made by the development team. All you need to define is tech stack, programming language and specify if there are any must-have integrations.
At the end of the day, most of the risks are solved during specification stage by our software architect and business analysts. This work is included in specifications price, as well as the search for suitable technologies.
Software Development Effort Estimation
Talking about efforts we need to answer three question: How long each task is going to take? Who do we need to deliver each task? How much will it cost? Time, People, and Money.
1+1 ≠ 2
There is a joke between Project Managers: two women won’t make you a baby in 4,5 months. Meaning you won’t speed up a project by 50% by adding one more developer.
One extra developer on the task gives no more than 30% speed boost.
“Why so?” you may ask. Well, to start, one needs to understand that we do not clone people but put a new individual. A man with unique brains, coding, and problem-solving approach. Add to this the simple fact that you can’t put two pairs of hands on one keyboard and the answer is clear.
Putting a second developer means dividing tasks on the project between several team members. But development pace won’t become faster inside a single task.
That’s why the budget often increases disproportionately to the number of specialists added to the project. If you want to speed up development works by 50%, you should get ready for ~70% budget rise.
Meantime, there is a way to help middle developers. That’s why we sometimes need to add a Team Lead or Senior Developer in addition to Project Manager. Senior Developer is a problem solver who is meant to mitigate risks and help middles with the most difficult tasks.
Team Leader is like a curator, who increases the productivity of less experienced programmers. For example, one middle developer will battle task 1,5 times faster if he will be backed up by the senior programmer. This way we can decrease development time without extreme rise in development costs. Because you’ll pay only for 3-4 hours of “senior backup” instead of hiring him full-time.
How many Senior back up hours your project will need? That’s where we need to define software risks, internal and external. The amount of time directly correlates to risks and uncertainties your project has.
Most of these risks will be solved by Software Architect at the project planning stage. He will find software solutions, third-party modules and code samples that are familiar to lower specialists, thus decreasing the need for senior programmers.
For everything else – there is the help.
The biggest problem is to answer “How much time will it get”. That’s where you go for experience. You probably heard of junior/ middle / senior qualification of programmers by the level. But this grading system is too rough to give accurate assumption about time. The error chance can be up to 50%.
For example, one middle-leveled programmer may require 5 hours and another one 10 hours to complete the exact same task. Of course, you can make time-limits and force people to stick to them. But this leads to the loss of quality.
That’s why we use our own qualification system for developer’s skills assessment. It’s based on historical performance data, types of projects he has worked on, and regular proficiency tests. Thus, depending on a developer’s grade, we can say more accurately how fast can the certain task be solved without loose in quality.
Now, when we’ve got all required ingredients, our Software Architect and Business Analyst can estimate time required for development. This task is performed by using several approaches:
- Group estimation – based on judgments of specific developers. This is by far the most undesirable way to make estimation because developers tend to overestimate time needed for certain tasks.
- Judgmental combination – based on estimates from a group of experts, senior programmers, team leads, PMs.
- Analogy-based estimation – based on previous experience and time logged for specific tasks.
- Expert estimation – This approach is used in 99% of quotes we make in our company. “Expert” means made by Software Architect and Business Analyst. During such estimation we utilize statistics from project management software. Plus, we use company-specific activity templates designed by our team.
An accurate estimate helps everyone. It helps stakeholders to have a confidence in their project. It helps a vendor partner to manage its own team. It gives our team members a reasonable development schedule, so they could work without a rush and deliver without loss in quality. And, of course, accurate quote reassures that you will get your product within a set budget and time.
Need a truthful quote?