Back to main page
Creating Good Software Development Cost Estimates in 2021
When clients ask us to estimate software development cost, we always aim to be as realistic as possible, going into detail and covering everything the project will potentially require. This isn’t because we’re looking to overcharge. It’s because we never underestimate how much work goes into building a successful product.
When estimating software development costs, ballparks are an important step for us here at Mooncascade. We try to get a strong understanding of what the client is looking for, what exactly needs to be done to accomplish it, and how much time and money it’ll actually involve. The idea is to give a clear idea of what the development process will require, not to rush to invoice anyone.
Like any other part of building a digital product, ballparks for software development costs should be made with a focus on detail, quality, and communication. Though cheaper estimates may be appealing at first glance, it’s important to understand what a good ballpark entails and why it’s often higher than initial expectations. Read on to learn why.
Getting a feel for the product.
Our ballpark figures for software development costs always start by digging into the client’s main challenges, to paint a clear picture of their business and development goals. It’s important to have an initial meeting or call, to learn everything we need to know in order to estimate the project’s workload correctly. We ask if the client has any concrete documents or mock-ups, find out if any pieces of the project are ready, or if they’ll be using another pre-existing system as a base for the new one. All of this helps us estimate the total software development cost of building the client’s product as closely as possible. The more information we get our hands on at this stage, the more accurate our ballpark will be.
To help you prepare for answering these questions, here’s a list of things the Mooncascade team usually ask over the first couple of calls:
- Understand the business and product:
- What’s the founding story of your business?
- What is the pain that you are solving for your customers?
- What are the main features of the product?
- Is it a completely new product?
- What platforms will the product be based on (web, mobile, back-end?)
- Or is it based on something existing?
- What existing components or parts of the system do you already have?
- Do you want to replace/update some of the existing parts of the system?
- What new parts or platforms do you want to add? (eg client has a web-based solution, but wants to have mobile apps also)
- Do you have some technical analysis documents or mockups?
- Describe the main use cases of the new app/feature
- Additional questions regarding the described functionalities and features, to get the best possible high-level understanding of the expected outcome.
- Do you have a specific technical stack that needs to be used for this project?
- Are you planning on outsourcing the whole development, or are there components that your own team will be working on? (eg outsource apps, work on back-end in-house)
- What is your expected timeframe for the project?
- What is your expected budget for this project?
If you’ve requested a ballpark software development cost estimate from a company and they don’t bring up any of the questions from this list, you can be sure they’re either dishonest or inexperienced. Remember, you can always help improve ballparks by sending your potential partner a proper brief ahead of time. We’ve put together a tutorial on how to write your own here.
Task breakdowns.
The next step in preparing a software development cost estimate is to break down each task the project will require into two main categories: design and development. Under design, we cover things like multiple language support and the cost of building landing and login pages. In the development section, we estimate the costs of setting up environments, architecture, analytics, push notifications, and CI/CD. We also go over the projected costs of code reviews and debugging, and we always include a feature mapping chart for both frontend and backend development.
This kind of detail work is important for several reasons. One, it ensures that nothing is missing from our software development cost estimate and that we’re in line with the client’s expectations. Two, it helps give the client a better idea of the actual amount of work that will go into making their product a reality. For example, an apparently simple feature like push notifications requires an entire dedicated backend environment to run. Even basic functionality needs to have a knowledgeable team behind it to work smoothly.
In addition to design and development, we also calculate the costs of quality assurance and project management in our ballparks. These can vary, as clients tend to have different preferences for how much they’d like to participate in a given project. In some cases, they like to be heavily involved, which significantly reduces the workload for our project manager and QA team. In others, we’ll be handling most of the work ourselves.
Giving a software development cost estimate with context and communication.
Our total ballpark estimate is calculated by adding the costs of design and development to the costs of QA and project management, which are based on the first two—either as a percentage or an estimate based on experience from similar work. In addition to predicting the project’s total cost, we also calculate a daily rate, which allows clients to approach their budget from another perspective. This can help when comparing offers, for example. If another company offers a lower overall price but estimates fewer days of work, this could be a red flag that they’ve underestimated how much effort the project will require.
Having put all of this together and made our software development cost calculations, we share it with the client in person, explaining our proposal instead of just sending over a number without context. We schedule a meeting and go over our ballpark with them, row by row. This allows us to discuss any questions that may have come up along the way. If the client has asked for something like a smart ID login, we might make a note asking whether or not there’s an existing service that could facilitate this. If a client has a limited budget and it’s clear that the project isn’t doable within their limitations, we can also offer to break their project down into phases and use their existing budget to deliver a first meaningful version, allowing them to find funding for the next phase while we work on the MVP.
We try to include this kind of out-of-the-box thinking in our ballpark software development cost estimates whenever possible, to add value at every step of our collaboration. Then, once we’ve covered any remaining feedback, we send the client a corrected final version and let them make their decision.
Why cheaper isn’t better when estimating software development cost.
To understand why cheaper ballparks aren’t better, you have to look at the context you’re working with. Some clients will give us a very thorough analysis of their project’s needs and standing, including fully-developed designs, mockups, and documents explaining planned functionality. In cases like these, our software development cost estimate will likely be close to what they expect. If our offer is still more expensive than others, this is due to pricing differences that depend on many factors—are you getting experienced developers or juniors, is the company in charge of the quality they’ve promised or have they outsourced part of your project development to some other provider? Quality always costs more.
Often, however, we partner with startups and innovation projects in corporations, where teams have an idea or pain point they’d like to solve but much less documentation to work with. In cases like these, we’ll still map out every feature, system, and process required to develop their product. But we’ll be doing it at a much earlier stage of the ideation process, which is why these kinds of estimates for software development costs usually end up higher than initial expectations. If a client has gotten a much cheaper offer in this context, it’s likely that the other offer hasn’t covered their idea’s scope as completely as possible.
We don’t overdo ballparks, we do them right.
From a sales perspective, it would be easy to lower our software development cost estimates for certain projects in order to outbid the competition. But if we did that and went over budget, everyone would lose: the client would feel cheated, our reputation would take a hit, and the final product would suffer from a collaboration built on poor trust.
Our goal when giving clients ballparks isn’t to overcharge. It is to predict, as closely as possible, the time, money, and effort that will go into building something well. Of course, estimates can change, especially if a project evolves in an unexpected direction or if a client comes up with new ideas during development. But in most cases, when we give an estimate for the software development costs of a project, we stick to it.
The best way to find this out is to partner with us. Clients can follow our processes, exchange with our developers, and enjoy our transparent approach to quality and communication firsthand. There’s nothing hidden behind our estimates—just a great team putting in the hard work to make your ideas happen.
