Article

Published: February 23, 2022

Jocelyn

Edited: February 23, 2022

How to estimate the cost of a software development project

Starting a software development project but not quite sure how much it would cost you? This article provides a list of considerations for your project costing.

Whether you are creating a proposal for a client or ready to mobilise an in-house software project, chances are you will need to estimate the cost of the project to price your proposal or seek for budget approvals internally.

Beyond the financing aspects known to project managers, product managers require these cost estimates for other reasons too such as to determine a product or feature success metrics, perform cost-benefit analysis, and develop a pricing strategy.

Personally, I like to provide just enough details in my estimations to ensure it is fit for purpose without being bogged down by specifics. Certainly the objective in performing these cost estimations would also determine the level of granularity in your calculations. For instance, coming up with an annual product budget does not require the level of breakdown as you might have in determining the success of a new product feature.

So let’s get down to the crux of things.

What are we we working with?

To understand how software cost is calculated, it’s important to know the objective of the project - whether it is to test a concept, demonstrate a product capability by means of an MVP, develop a new product or improve an existing product or feature.

Understanding the nature of the project helps determine the necessary ingredients (exemplified in the cost breakdown) and manpower you will need.

Determine the nature of the project

In software development, there are typically four types of projects you can embark on based on your objectives. The simplest in terms of delivery is a proof-of-concept (POC) project which is used to prove and validate an idea, often stemming from a single well-defined problem that is critical to the future success of the product.

On the other extreme, the most complex projects involve building a full-fledged product or an ultimate solution from scratch with a large backlog. Simply put, the more requirements you have, the more complex the project becomes.

These projects are usually phased to incorporate product decision checkpoints in between and it is also an approach to protect your client’s financial interest especially when they have limited budget to spend at a particular point in time. Though they may seem like isolated projects, each project is in fact adding incremental value to the end-state solution - as seen with Agile.

Types of software development project

Types of cost in software development

Regardless of the nature of the project and the level of commitment, cost to develop a software product can be broken down into:

  • Hardware cost
  • Software cost
  • Labour cost (acquisition cost is excluded from this calculation)
    • Project Manager
    • Business analyst
    • Product Manager
    • UI/UX designer
    • Infrastructure
    • Back-end engineer
    • Front-end engineer
    • Quality Assurance

Note: Acquisition cost entails the cost to hire a talent and to procure the necessary personal hardware such as a laptop and software and productivity tools for the individual to perform his job.

Development cost varies between types of projects

Scope the project

Now that you know the different types of software development projects and costs to account for, the next step is to scope the project.

Teams often conduct one or more rounds of Design Thinking to brainstorm on possible solutions to their problem statement. Product managers would then rally the team to come up with a preliminary list of features to build, product requirements, and design requirements with the help of designers.

The next step is to discuss with the engineering team to nail down the engineering requirements and get a sense on timelines and velocity for delivering the features. At this stage, do expect some tweaking to the initial feature list and design based on the technological feasibility to implement these features. By the end, you will most likely end up with:

  • A requirements backlog with the necessary implementation steps
  • The application design schema
  • Prioritised product roadmap
  • Hardware and software cost estimations for each feature (as advised by your engineering team)
  • Time estimations and velocity to deliver each feature (as advised by your engineering team)

Product development example

To put this into perspective, let’s dive into a hypothetical project of developing a fintech app from scratch. Broadly, this app helps users to manage their investments across different financial products, with users being able to perform the following actions.

Features of a fintech app

The examples above are not exhaustive but they should already give the team a sense of how extensive the work and cost would be. In a real-life scenario, these requirements are documented comprehensively as Epics and User Stories by Product Managers.

So what are the cost considerations do you need to keep in mind before developing the product?

Hardware

In this scenario, you will need to assess what hardware is readily available and what additional hardware you will need to procure, especially if this is not the first product your company is building.

Right off the bat, you will need a place to store or host and process your data i.e. servers. Nowadays, it is common for businesses to use a Cloud service like AWS or AliBaba Cloud where you can rent instead of owning the following components:

  • Hard Disk Drive (HDD)
  • Solid State Drives (SSD)
  • CPU power
  • RAM (for storage & processing)
  • Graphic processing power

These providers offer pre-packaged services at a fixed monthly rate but these packages can also be customised to meet the growing needs of operations. Typically, the engineering team makes such buying decisions. It is important for the team to understand their own code and requirements to ensure you procure only what is needed to keep operating cost optimised.

Technology / Software

The next cost consideration pertains to your technology stack or software you need to support your features. Typically for any software product, you will need to factor in:

  • A database
  • A web server
  • Domain and SSL certifications
  • An email provider
  • Membership fees with Google, Huawei and Apple
  • Software Development Kits (SDK) e.g. e-KYC in the case of our app
  • Other third-party monitoring and analytics tools

When procuring these software technologies (excluding open-source software), be familiar with their pricing structures. You could obtain them for free for a period of time, on a monthly subscription or through a license which may entail a specific agreement with the third-party provider. Often, a license is a one-time purchase of a software for a stipulated period of time.

It’s worth noting that with POCs and MVPs, it’s possible to create a leaner list of software required. After all, the objective of such projects is to prove a concept and to build the simplest workable product. For instance, a simple Excel sheet may suffice in place of a database technology.

With these technologies, comes the question of integration which requires specific skill sets and expertise to execute.

Labour

Arguably the most critical aspect of project costing is the core team. I like to plan by first understanding the requirements and identify the skills required to build the product or feature. Skills are then matched to the appropriate resources with their respective list of tasks required to accomplish the job.

Again, depending on the type of project, the team size may vary from a few engineers to a full-blown team consisting of product owners, product managers, project managers, a large engineering team with dedicated roles, UIUX designers, business analysts, and even data experts.

The other consideration when it comes to resource costing is the list of features to build. As mentioned, the more features you have the more complex the project becomes, thus requiring more time for planning and coding which impacts the overall development velocity and cost.

The level of integration required also plays a big part in deciding how much time your engineers would spend reading API documents and user manuals. In fact, if third-party softwares are selected, they may not even require extensive integration, thus saving you time.

Due to the different paths a project can take, a project can span anywhere between 3 to 6 months or potentially longer. For a POC and MVP, the duration can be as short as 2 to 4 weeks.

Now that you have understood how resource efforts in man-days are allocated, the next step is to calculate the cost of these resources in dollars and cents. To do this, each member of the team would have their own rates, typically by level of seniority, which is a function of their salary plus a contingency of e.g. 20%.

Of course, there is then the question of outsourcing vs. developing in-house. Businesses choose to outsource mainly for two reasons: to acquire specialists where there is a skill gap in-house or to outsource operations so the core team may focus on more value-adding tasks such product and engineering strategy. Do expect a higher man-day rate when contracting an external consultant.

Future-proofing: Forecasting cost

The methodology used above is used to estimate the cost of software development. But as you’d probably know, with Agile, you can’t really say for certain what you will ultimately end up building. At best, you can probably only estimate based on your feature backlog and foreseeable requirements.

However, it is important to keep in mind that your estimations should take into account the growth forecast of your user base, feature list, and future integration requirements. The more details you can provide, the better your cost estimations will be.

Though the devil is in the details, granular calculations are best reserved for only use cases that require them. For instance, you can very well do with man-days instead of man-hours, and high-level product features or epics instead of detailed features or user stories.