When a company or individual looks to estimate the cost of software development, inevitably questions like “How much?” and “How long?” are asked.

Two questions define the constraints that most clients experience in project work – “Can I afford this?” and “Can it be done in time to meet my expectations?”. Almost every sales meeting regarding software development revolves around getting answers to these questions. Often customers don’t realize the factors that affect the cost of software development. Estimates of software development costs can vary and the estimate process is not transparent to customers.

Here we outline what goes into estimating the amount of effort and costs of a software development project. These points will clarify the difference between timeline and effort, explore what factors are utilized to come up with an initial estimate, then discuss specific examples of projects with pricing estimates. 

Every engagement is unique and there is no one simple formula that will work for EVERY scenario. That said, we at TIGOSOFTWARE have been helping companies for over a decade and are happy to share a few rules of thumb to use when estimating project cost. We’ve been able to identify 3 main components that have the largest effect on project cost and timeline.

3 Main Factors of Software Costing

Let’s explore 3 main factors that most affect software development effort/pricing:

1. Type of Software Project
2. Size of Software Project
3. Development Team Size

1. Type of Software Project

From a high level, typical software development engagements tend to break down into the following types:

• New Software Development: new software, involving custom development.
• Software Modification: Enhancement of existing software. 
• Software Integration: Custom code to add capability or integrate existing software into other processes. This would include plugins to packages like Office as well as manipulating data flowing between an inventory system like Netsuite with an accounting system like Quickbooks. 
• Web Development: custom web-based software development

Each of these types of projects typically has a different team makeup and requires a different amount of development effort. Understanding the type of project is the first step in developing a cost estimate. This information will be used in combination with the size of the project and the project team to determine the final estimate.

2. Size of Software Project

The next step is to determine the size of a project. Size is a bit of a gut call. There tends to be a tight correlation between the complexity of a project and its size, but that isn’t always the case. Generally, project sizes fall into the following categories:

Small size 

A small project usually involves minor changes. Typically, things like tweaks to the user interface or bug fixes that are well defined with a known cause. Interaction with the client is limited, i.e. “Is this what you want to be done?” followed up by, “Here is what we did..”

Medium size 

These engagements are more substantial than a small tweak but likely have a well-defined scope of deliverables and are often standalone solutions or integrations. Typically, we are dealing with a single source of data. Projects such as a small mobile application or a web interface to an existing inventory system would fall into this category. The external requirements for interaction with a client are more robust than small projects. This might include a few design sessions, weekly check-ins, and milestone sign-offs.

Large size 

These solutions include more depth and complexity. Large projects may require integration with multiple systems, have a database component, and address security and logging features. An underlying framework and a module-based design are common, taking into consideration scalability and maintainability. A multi-party application that works across numerous platforms (iOS, Android, Web) would fall into this category. The external requirements for interaction with the client are very robust, i.e Extended design sessions and milestone agreements. Daily calls and interactions with technical team members followed by weekly status calls with higher-level management are standard.

Enterprise size 

This level would be a large project on steroids. Enterprise-level projects are almost exclusively built upon an underlying framework. They have much more rigorous security, logging, and error handling. Data integrity and security are paramount to these business-critical applications. Though not exclusive to this category, support systems are built to be resilient and able to handle 2-3 concurrent faults in the underlying infrastructure before having a user impact. A mobile app like Uber would be an example. 

The external requirements for interaction with the client involve fully-integrated client and IT teams. Time requirements include extended design sessions and milestone agreements across multiple teams; daily calls and interactions with technical team members across multiple groups/disciplines; weekly status calls with higher level-management; quarterly all-hands meetings.

Using Project Types and Sizes to Determine Time Estimates – “How Long?”

Now that project types and sizes are defined, they can be combined to put together the following possible timeframes:

This grid provides a good starting point to estimate a project’s timeframe. Sales and Delivery can now give a quick estimate to clients regarding how long a project will take.

3. Development Team Size (per Project)

Once the project is defined in terms of type and size, the next factor to be determined is the team size. Every project requires at least 3 roles – a Project Manager, a Developer, and a QA Tester. However, that does not mean that every role equates to one team resource. Some resources can fulfill more than one role.

For example, In a small project, a Developer may also fill the role of Tester. In a small/medium project, the Project Manager may also fulfill the role of Business Analyst, and so forth. For larger, complex projects – team resources usually fulfill only one role to effectively move the project forward.

Rough estimates of team sizes may include the following structural roles:

PROJECT SIZE
* means required resource

The Final Step to HOW MUCH?

Straightforward Estimate

The most straightforward way to estimate project cost would be:    Project Resource Cost x Project time = Project cost

Unfortunately, it is not that easy. As mentioned earlier, some resources may play more than 1 role on a project. Most resources do not work full-time on a project – for example, once anyone in a design role is done (Architect or UI/UX), there is no need for that resource to remain on the project 8 hours a day. They may be needed to confirm coding is meeting design requirements, or be available to tweak the design, but full-time is no longer necessary. 

So you may be asking yourself, “Why would I pay for a full-time project team when the entire team is not working full-time?” There are a couple of answers to this question. 

• You don’t pay for a full-time project team as the costs of the team are averaged based on the amount of work each resource completes per project. For example, the effort of a tester is usually expected to be a percentage of the entire project. The cost of a tester is based on this percentage.

• If your project requires a team, you are paying for a mix of skill sets. That means you have access to premium skill sets at a lower cost because you are only paying for a percentage of that person’s time. 

• Scheduling and maintaining a dedicated project team is instrumental in completing the project most efficiently. There is nothing more detrimental to a project than continually stopping and starting- it can be hard to regain the momentum to get the project back on track. 

A project team should work like a well-rehearsed production. Done well, necessary resources come on and off the project with no noticeable lapses in productivity.

Rough Estimate

To obtain rough cost estimates for a team, let’s utilize the following numbers:
These numbers do not reflect actual pricing of TIGO software development but rather, they are what we use to provide a ball park to work from.

• ~ $150/day for a developer (*)
• ~ $1500/week for a team (*)

(*) many factors affect the pricing of a technical resource and team – experience, role, size, location – these prices represent rough costing for quick estimation

Now applying the cost of a team with the project time estimates from the chart above, we can finally come to a project cost. Using these numbers as a guideline, and assuming a certain benefit from scale (meaning larger projects results in better costing/week), we come up with the following pricing chart based upon our time/complexity grid:

Sample Projects & Costs

The point to remember with this exercise is that the numbers are an ESTIMATE to get an idea of how much a project will cost and how long it will take. If the estimated cost is reasonable to everyone, then a more detailed quote can be generated, followed by a full project plan outlining the actual costs and milestones. Unless unknowns are discovered, detailed project costs tend to be within 10-20% of the cost using this method.

To put this all into context we put together the following list of representative projects:

Bug Fix – known issue

Resolution of a known issue in existing software that we are maintaining. This assumes that the cause of the issue is known, and the issue affects a minimal number of objects.

Type: Software Modification
Size: Small
Time Frame: 1-2 weeks
Cost: $1k - $5k

Proof of Concept (PoC) Applications 

Often the first step for many startups, these projects tend to focus more on the look and feel of a new application and the possibility of achieving the desired outcome, more than providing functionality.

Type: New Software
Size:  SmallTime Frame: 4 - 8 weeks
Average Global Cost: $25k - $35k
Average TIGO Cost: $15k - $25k

Mobile Applications 

Standalone application for iOS and Android. Moderate data collection, location awareness, secure cloud database interaction, push notifications, and administrative portal/functions.

Type: New Software
Size: Med
Time Frame: 4 Months
Average Global Cost: $60k - $70k
Average TIGO Cost: $30k - $50k

No-code/low-code development

No-code approach differs from high-code (or traditional) development, as it doesn’t require any coding experience. No-code platforms offer a visual development environment where users without technical background can build basic apps by dragging and dropping UI elements into the development canvas. However, this development method is only suitable for applications with limited scope. Customization options are rather limited, and legacy systems can’t be involved.

This approach helps non-technical users create prototypes to convey their product vision to the technical personnel. It’s also possible to build full-blown applications for a relatively small audience.

Low-code development is the middle ground between no-code and traditional development. You can create a basic application using visual elements, but you can also customize and add complex functionality by accessing the source code. As a rule, low-code platform vendors provide extensive documentation and tutorials.

Type: New Software
Size: Med
Time Frame: 2 - 4 Months
Average Global Cost: $40k - $60k
Average TIGO Cost: $15k - $30k