The very first thing clients want to find out after sharing their idea of a product is the price for the project development. It’s also what you need to know before signing the contract, isn’t it? This is what a rough estimate is all about.
Most of the companies that build apps can provide a project estimate. The estimate shows what the company charges for and the time needed to complete each task. We at MindK provide our clients with both rough and detailed estimates.
A detailed estimate takes a lot of time and no one has much to spare, so you can ask for some advanced napkin math to get an approximate budget for the project and to see if the developer is up to the task. This is where rough estimate comes into play.
Now we will explain what a rough estimate is and how we do it here in MindK.
What is a rough estimate?
This document, sometimes called ROM (Rough Order of Magnitude), gives you an approximate price of your app.
It estimates the time required to complete the project feature by feature. Multiply that by the developer rates and you’ll get a ballpark sum you can use for budgeting or to compare different bids.
A rough estimate is based on the client’s brief and is delivered within 2 days of receiving the business requirements.
A rough estimate alone isn’t enough to draw up a detailed budget but can serve as a roadmap for your project.
Note: in software development, the final price can differ by up to ± 50% from the initial estimate depending on the amount of unknown data.
The document also shows whether the developer in question has/we have enough resources and expertise to deliver the product.
The feasibility study that is a part of ROM will reveal if there are any limitations that could hamper the project.
If we discover such hindrances, we suggest any possible alternatives to our clients and include the time for research and training in the estimate.
The document outline
Our rough estimates typically consist of five sections: the estimate itself, our assumptions, our suggestions, the limitations, and our questions.
1. Estimate
We break down the functionality of your app into separate chunks. At this stage, the chunks are too big to be called features, so we prefer the name epics. Each of these epics is evaluated separately by our expert team. They estimate the time needed to implement each of them.
The result is you get a work breakdown structure along with the costs of each epic.
We provide the breakdown of costs into one of three formats:
- Price range where we include both our minimal and maximal estimates (5 to 10 hours);
- Mean value (7,5 hours);
- Only the minimum amount of work (5+ hours).
This choice depends on each client’s individual preference for the precision of estimations and the clarity of requirements (i.e. with the well-defined requirements we provide our clients the mean values, but if the requirements are extremely imprecise we can only prepare the minimum + estimate).
The format further depends on our understanding of the feature (i.e. we can give a much more precise estimate for a feature we’ve implemented dozens of times vs. a feature we’ve never had to deal with).
We also dedicate a separate subsection to the standard features.
From our experience with developing web and mobile applications, we know that some of the features and tasks are common to all applications. In this section, we list the setup of servers and environment, the discovery phase, project management (if required), App Store release (for iOS apps), etc.
2. Assumptions
It’s impossible to cover all the aspects of your future app during a single conversation with the developer. That would take hours upon hours of extremely thorough discussion. But time is a precious resource and our clients can’t waste any.
Our briefs are called that for a reason. They are for the essentials, not the miniscule details.
One way to deal with this is to ask a ton of follow-up questions. But such practice would only confuse our prospects and drown them in the irrelevant technical details. So we use a different approach.
Our experts make a number of educated assumptions.
We use our experience with web and mobile development to assume the best possible ways to resolve any uncertainties in the initial requirements.
For example, if a client only provides the design for the main page, we assume that the design for all the other pages isn’t radically different (unless, of course, stated otherwise).
If a prospect doesn’t stipulate the multi-language support for their app, we assume that the app will be monolingual (i.e. English only).
All in all, this practice cuts down the time needed to prepare the rough estimates and saves our clients from some extra annoyance.
3. Technical Suggestions
In this section, we use our expertise to suggest the best technical solutions to our client for the posed requirements. We recommend the optimal tech stack (including the choice of programming languages, frameworks, and libraries) both for the application’s back-end and its front-end.
But it’s not necessary to reinvent the wheel each time you make a new app. There are literally hundreds of ready-made solutions out there for pretty much every routine operation or common problem.
We also make various non-technical suggestions such as ways to keep your project within budget. We often suggest that clients narrow down the project’s scope and move the non-essential features to later releases.
4. Limitations
In this section, we look into the project’s feasibility as every tech solution out there has its limitations.
Rest assured that we’ll inform you on any constraints that can impact the development of your app.
If our clients, for example, want their app to support Android 4.1, we point out that this is an outdated version of the OS and that the majority of consumers uses Android 4.4 and higher. We note that the support for Android 4.1 can take a lot of time to implement for little to no gain. We then suggest changing their requirements to Android 4.4+.
For web applications, we may list in this section the versions of browsers supported by the application.
We also point out if some of the tech is new to our team and allocate the appropriate time for research and training.
5. Our Questions (optional)
Although we aren’t fans of spamming our clients with hundreds of questions, it’s better to address some of them as soon as possible. If there are any unclarified points for us, we will provide you with a few additional questions along with your rough estimate.
Conclusion
A rough estimate is a neat little document that gives you the idea of how much your app will cost.
Moreover, it gives you the work structure breakdown, so that you’ll see which of the features are the most labor-intensive.
Lastly, it shows whether a developer is really up to the task of creating your app.
But a rough estimate is just an outline, a first step towards the fruitful cooperation. The next step is signing a contract and a rigorous preparation stage during which we prepare the detailed estimate, a thorough document detailing every costs-related variable. We’ll write more on detailed estimates in the next post.
Have any questions regarding the rough estimates at MindK? Just drop us a line!
