Every client of ours is provided with the project estimate. The estimate explains what we charge for based on the amount of time needed to complete each separate task. We provide two types of estimates: rough and detailed. In this article we’ll talk about how we make a rough estimate.
All our clients receive a rough estimate within five business days after they submit their requirements. We break down the whole project into smaller chunks, and allocate hours against each particular one. We also can add a certain risk buffer for unseen tasks / error handling, bug fixing, etc.
The purpose of a rough estimate is to give our client an approximation of cost within a range of required functionality. This document serves for information purposes only.
Our rough estimate consists of five chapters:
lists all chunks of functionality with hours needed for their implementation.
We specify a rough maximum and minimum amount of hours required to accomplish a given task. These values can give client some understanding of the scope of work.
estimates feasibility of the project.
It may happen that a project or a given function cannot be implemented due to some limitations of a mobile platform, a lack of resources, or other issues. In this case we try to look for another solution.
Some features may also require knowledge of a certain technology or service that we have never worked with. If this is the case, we’ll supplement our estimate with additional hours needed for its research.
specifies intensive components.
These components usually require a lot of time and budget, so we distinguish them to suggest our clients more cost-effective ways. We can offer to alleviate a component, use an alternative solution, or move a given feature to the next app versions if possible.
For example, if there is a chance to choose between real-time and non-real-time messaging, we can suggest to start with non-real-time since this solution is faster to develop, and, therefore, less costly. Real-time messaging can be added at a later date.
A particularly complex technical solution estimation requires a certain amount of time. That’s why we typically consider it during the project planning stage — a preparation process that takes from two up to four weeks before the first iteration.
includes our questions.
The effectiveness of communication with a remote team depends – among other things – on the way requirements clarification is performed. Therefore, we try to be as specific as possible so that a client doesn’t have to send us any clarifying questions in reply, which will hamper the process of collaboration.
Questions: “what do you want to notify your user about?” and “what service would you like to use for push notifications?” might trigger a back response: ”what options are there?.” Instead, we’ll ask the following questions regarding push notifications:
Depending on client’s answers we introduce changes to the rough estimate.
offers our suggestions.
Our suggestions pursue a goal of improving and optimizing both design and technology of a given project.
For example, if client wants to develop a clone of a popular app, we will suggest that they use some design features that will make their app look unique. It can be an interesting pull-to-refresh animation, a redefined hamburger menu, or anything else that fits a given application. Even a small feature can make a big difference in user experience.
Regarding the technology stack, we carry out similar apps research and suggest a number of frameworks and libraries that proved to be efficient there. We also tend to offer the services and tools that we have enough experience with.
Not all rough estimates manage to meet customers’ expectations. But we care about every project and put a lot of effort into helping all our potential clients. Therefore, if the scope of a project exceeds the allocated budget, it can be an effective solution to cut down some features to showcase just the core concept.
Not only does an MVP shorten development process and cost, it also reduces apprehensions about risks involved in building a sustainable product. We glean features for an MVP based on market analysis taking into account a preferable business model.