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.
