Guides to shaping great products

What do companies that build apps mean by ‘Rough Estimate’ (and how we do it in MindK)

Time for reading: 6 min

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.

It will show whether your solution is a $10,000 app, a $100,000 app, or an app that requires funding and resources on par with Facebook or Instagram.

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.

e-book agile development

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.

Example of Rough Estimate in MindK

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.

Standart features in rough estimate (MindK)

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.

Along with rough estimate we advise readily-available solutions that can be integrated into the client’s app. This reasonable practice results in saving both our time and their money.

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!

Frequently Asked Questions

  • How does the accuracy of a rough estimate compare to that of a detailed estimate?

    The accuracy of a rough estimate versus a detailed estimate varies significantly, with rough estimates providing a broad overview while detailed estimates give a granular breakdown of costs. Deviations in the final cost often arise due to unforeseen project complexities, changes in project scope, or external factors impacting development.

  • Can the process of creating a rough estimate be expedited for projects with extremely tight deadlines?

    Yes. However, you need to prioritize key project elements or leverage previous project data for quicker assessment. Such acceleration might reduce the estimate’s accuracy due to less time for thorough analysis.

  • How does MindK handle changes to the project scope or requirements after a rough estimate has been provided?

    When project scope or requirements change after a rough estimate but before detailed estimating or development begins, a common approach is to reassess the project’s scope and provide an updated estimate. This involves communication between the client and the development team to understand the impact of changes and adjust the project plan and budget accordingly. You can learn more by reading an article about the change control process at MindK.

Subscribe to MindK Blog

Get our greatest hits delivered to your inbox once a month.
MindK uses the information you provide to us to contact you about our relevant content andservices. You may unsubscribe at any time. For more information, check out our privacy policy.

Read next

Digital Transformation in Education: Redefining the Experience of Everyone Involved

Digital Transformation in Education: Redefining the Experience of Everyone Involved

Read more
Digital transformation in insurance

Insurance Digital Transformation: 4 Emerging Business Models

Read more
Rewriting Infrastructure as Code and Streamlining the Release process for a Large FinTech Startup[Case Study]

Rewriting Infrastructure as Code and Streamlining the Release process for a Large FinTech Startup[Case Study]

Read more