App Cost Estimation: Our Failure and Lesson Learned

We would be lying to say that everything in our work goes smoothly and flawlessly. It’s a sure thing we encountered failures on our own journey of software development. Moreover, we’re not scared of talking about them as they are a part of the progress and growth. Though we haven’t faced lots of failures, we decided to write an article about them. We believe our failures and how we find a way out of them speak best about our work and expertise.

The most common failures that occur in app development are:

• Incorrect app cost estimation;
• Misunderstanding of expectations;
• Technical failures.

Today we would like to tell you about our failure in app cost evaluation that put us in a tight corner and lessons learned out of it.

How We Failed in Mobile App Cost Estimate

In the early days of Celadonsoft, we were approached by a customer to develop a mobile application. It was not supposed to be developed from scratch, because they already had a backend in place and needed to develop the frontend.  

We usually work on T&M because the contract is billed for the actual effort spent on software development, regardless of the stage of development. Due to our inexperience and willingness to undertake the project, we went along with the customer and agreed to a Fixed-price contract. It may be an effective choice when requirements, specifications, and rates are well predictable but it wasn’t our case as it turned out after we evaluated the project and calculated the cost to develop an App. 

As is customary, upon obtaining the client's requirements related to the project, we carried out an interview with them, where they provided us with the details about the project. Based on the information provided, our team estimated the cost of application development, evaluated the work scope, set the timeframe, and determined the number of people needed to accomplish the work on the project. At the end of estimating, we arrived at the assigned 3 people and specified the timeframe of 4 months. The client insisted on fixed price pricing and the requirements and app evaluation results seemed to be sufficient enough to agree working upon such conditions.

The contract was signed and we set to work. After we had been shared access to the repository (the place where the code is located) and obtained the code, we realized that expectations and reality were a completely different kettle of fish. We did a review of what we received and found that the backend was done poorly. First, it was unfinished. Second, half of the declared features and functionalities were absent. We had a much bigger work scope ahead:

• Rewriting the backend;
• Developing an Android application;
• Refreshing UI/UX design;
• Setting monetization;
• Rewriting the native iOS application to have a single code base for both platforms;
• Improving the overall maintainability of the system.

Looking at the scope ahead, we realized that we made a fatal mistake by signing the Fixed price contract, and we were up the creek without a paddle. 

Analyzing the app cost estimation process showed us several reasons why we failed: 

• We didn't properly interview the customer, i.e. we didn't get enough information, or access to the product and materials.
• We did not do a qualitative mobile app cost estimate for the Fixed price pricing because it was impossible to do due to the abovementioned reasons.

But the app cost estimate was made as it was, and the contract was signed, so that’s the way the cookie crumbles. The error was ours. Re-negotiating the contract was not an option for our team. Neither lying down on the job was our principle. Besides, if we had chosen one of these options, we would have risked, fouling our own nest and incurring other risks, which we couldn’t allow this happening. We were fully aware that the responsibility was on our shoulders, so it was up to us to solve the problem. 

Mistakes can be costly. Our decision also required us to work through the loss. We assigned out-of-contract people to join the development team. So, the team composition was as follows:

• Project manager;
• 1 full-stack software engineer;
• UX/UI designer;
• 1 mobile frontend engineer;
• QA/DevOps engineer.

In addition, the duration of the project was also prolonged - 7 months against 4 months under the contract. 

But the lesson was learned. The app pricing to be applied is determined after we interview and evaluate project costs with a fine-teeth comb. In most cases, we prefer working on Time & Materials, with the exception possiblefor the cases when:

• A client has a clear understanding of what is needed to be done. The requirements are disclosed in Technical documents and no changes are expected. After reviewing the requirements and documentation, we sign NDA and conclude the Fixed price contract.
• When a client is a startup with a limited budget. In such cases, we conduct research and consult on the features and functionalities that will work best in MVP. Thanks to our accelerated experience, we have a sense of what the market will accept. 
• A client brings research with an SRS from a third party. The SRS is a document that contains information on the goal, technology, platforms, tasks, etc. Having this document, the development team will have a clear vision work scope and estimate an app development cost for a fixed price.

How We Conduct app Cost Estimation Now

Our ups and downs have put us on the path to changing the app cost estimation process. Now the process is more deliberate and refined if compare to the one we did before.

Previously, it was the sales manager, the CEO, and the developer who did the app cost estimation. The customer would send a request. The sales manager contacted him, discussed the idea of the project, and gathered the requirements. Requirements and information about the project were transferred to the developer, who estimated the work scope and required hours. Based on this information, the application cost estimation was made. 

After failing to estimate the cost of the application, we felt it was time to create an RFP team. RFP stands for Request for Proposal. The RFP team consists of three people: a team leads PM, a business analyst, and a senior full-stack developer. 

What the evaluation process looks like right now: 

• Sales department communicates with the customer and collects requirements;
• Information about the project requirements is then sent to the RFP department;
• Based on the requirements, PM, BA, and Full stack developer calculate the application development cost and determine the work scope;
• In addition, the RFP department can provide recommendations on project implementation based on the team's experience. 

After our team reviews the requirements and scope of work to be done, the decision on the app development pricing method is taken. 

Mobile App Cost Estimation: Fixed Price vs Time & Material

As you may guess, a fixed price is a contract where the project requirements and costs are set in concrete. A Fixed-price contract defines the scope of development a company must do for a Fixed price. A client gets a total price for the project, not per hour or task. 

Based on our mistake and experience, we may consider working on a Fixed price contract in cases when:

• We’re provided with precise requirements and deadlines and they will not be modified;
• A client has a limited budget;
• A request is to develop an MVP;
• The project has a little scope.

The Time and Material contract bills the total actual amount of work based on a daily or hourly rate, regardless of the development milestone.

Cases where it is better to opt for TM:

• The project scope is rather extensive;
• The requirements are not completely known and can be changed in the course of the project;
• The client wants to be able to flexibly change the scope or change the functions in the course of the project.

Both of the approaches have their pros and cons. Our failed experience of working under FP contract helps us highlight the pluses and minuses of both pricing methods more clearly.

Get Your App Cost Estimation Done

Usually, at the start of large projects, customers rarely have an exact idea of all the functionality they need. However, as the project develops, our team together with the customers gets deeper into the tasks - new ideas and improvements emerge. Time and Materials is very convenient in this case - you can make adjustments directly in the course of the work.

Failures are part of progress. We do not hide the fact that we have had failures and mistakes in our history, from which we draw conclusions and lessons learned. Also, we're not afraid to talk about things we've screwed up, since that's a part of our expertise, too. 

Now we know that quality communication and discussion of all the details will help us to choose the most suitable payment model, to calculate the budget effectively. 

We can confidently state that Celadonsoft is a development team with large expertise and experience that is able to find the way out of complex circumstances. We can provide both Professional Mobile App Development and Professional Web Development Services. Also, we can take over your unfinished projects and do software projects rescue. Whatever your need is, contact us to start collaboration.