Let’s start by defining what we mean by “custom business software”. In this context, we mean internal or customer-facing software that facilitates the operation of the business, either by automating processes, providing business intelligence, access to information, or integrating multiple systems. Developing software is a complicated process that requires a valuable set of skills and experience.

Requirements around:

• security,
• uptime,
• performance,
• regulatory compliance

add to the complexity when developing business applications. 

For mass market software or SaaS applications, the cost is spread across a large pool of customers, but that’s not the case for custom software.

However, “expensive” doesn’t always mean “not worth it”. 

Custom business software can:

1. reduce errors,
2. increase efficiency,
3. lower labor costs
4. or give a business a competitive edge.

If you’re interested in having custom business software developed, here are some factors worth considering that can impact the cost.

Why some development companies are more expensive than others

Here are the primary reasons some companies can be more expensive than others:

1. Skill Level
2. Corporate Certifications
3. Company Size
4. Company Experience and Expertise
5. Team Size
6. Estimation Quality
7. Location, Location, Location

Skill Level

The skill level of software developers combined with the scarcity and demand of their skillset impacts their wages. 

Developers with extensive experience, specific education, or certifications demand higher wages and therefore higher rates.  The expected upside to these higher rates is an application that is developed at a higher quality or a faster pace than with less skilled developers.

Corporate Certifications

Business processes / workflows can vary widely from organization to organization, but there are certain certifications or credentials that organizations can earn that tell a prospective customer that their processes have been “standardized”, offering a level of comfort to some organizations (e.g. ISO).

The effort and costs associated with earning and maintaining these credentials can be pricy and time-consuming, which many times will be reflected in higher pricing.

Company Size

Larger companies tend to have more overhead by way of more robust marketing, accounting, legal and HR departments, etc. But they also tend to be more experienced and can be more stable.

Smaller companies can often be more agile and deliver lower development pricing, but may not have the longevity or breadth of experience of a larger firm.

Company Experience and Expertise 

Some software development companies focused on specific types of applications (CRMs, ERPs, Ecommerce etc.), or focused on certain industries (e.g. manufacturing, medical, financial etc.) tend to have in-depth knowledge of their markets.  This experience may result in higher rates for their projects with the hope or expectation of better or faster results.

Team Size 

Development team size can vary widely from large teams of developers, project managers, system architects, QA technicians and more, to small teams of one or two people wearing many hats. 

Larger teams tend to have isolated job roles filled by team members with specific experience or skills.  When well-organized, this approach can yield quality development at improved speed, but due to the quantity of resources on the project, may incur higher costs. 

If not well organized, larger teams can suffer from communication issues and lack of overall project ownership. This can result in cost overruns. 

Smaller teams may face fewer communication or organization difficulties which can improve development efficiency and yield lower costs. On the other hand, smaller teams may not have the breadth of experience or desired skillset proficiency, which can increase the time and cost of a project due to a learning curve.

Estimation Quality

Firms use different approaches to their estimation process. 

Some may provide quotes based on a minimally viable product (a piece of software that has only the necessary functionality to be used), while others may provide an estimate for a fully functional, robust application.  The differences in approach can drastically change the scope and therefore the estimated cost of the software application.  Here is how we approach estimation of a software dev project at Keypress: our software development process.

Location, Location, Location 

The cost of labor, even high-tech labor such as software development, varies greatly around the world.  Many software development firms are located in countries where labor is much less expensive. Some US-based firms offshore (or nearshore) their development work to these countries. 

Some companies have had great success in reducing costs by offshoring their development efforts without any loss in quality or delays.  Yet some offshore efforts suffer from communication issues due to language barriers or time zone discrepancies.  Offshore teams at times are unfamiliar with the terminology, and user expectations of different countries and can be difficult to hold accountable on project quality or completion.

The old adage “time is money” comes into play in software development since software development is a time intensive process.  So, when looking at the costs of development the main factors at play are: (1) how long it takes and (2) how expensive that time is.  So that brings us to our next question…

Why software development takes so long

There is a common misconception that software development is a simple and fast process. 

However, the reality is: developing useful, quality software is a complicated, time consuming and sometimes tedious task that requires various skillsets. 

Here are some aspects that make software development take so long:

Project Scope

What are you developing?  What problem are you trying to solve and how complicated is it?  Identifying what you want to do and how you want to do it is an important and sometimes time-consuming step.

For example, when you’re looking to develop a new application to replace a legacy software system, you’ll need to:

1. Have a full understanding of every function of the old software.
2. Consider not only what the legacy system does for its users, but also its impact on non-users (e.g. users in other departments, report consumers, and customers). 
3. Understand all third-party system integrations so that no functionality is lost during the transition. 
4. Identify and scope out areas for improvement.

Architecture

Once you know what you want your software to do, identifying the best technological approach to building it is critical.

A few high-level decisions that need to be made:

1. where the application should be hosted,
2. what language stack should be used,
3. whether there will be a need for external integrations. 

For example, developing an application for use by a few in-house employees accessing an application on an internal network is very different than building an application for the masses with peak volume during certain hours.  Understanding what load the application will have, and planning an architecture to handle it, requires effort and know-how.

Data Structure

Most applications are based on data.

Understanding the data you’re dealing with and how best to structure it for the application so that:

1. users can find what they need in an efficient manner
2. the data is well organized

requires skilled database professionals.

UI/UX (User Interface/ User Experience)

Everyone wants software that’s simple to use. 

Designing software with that quality takes effort and experience.

While most front-end devs can develop intuitive screen designs, some applications require more advanced UI/UX. 

For example, there’s a large difference in UI/UX requirements between:

1. an application where a small number of users access the application and can be trained vs
2. an application with a broad nationwide userbase with a wide range of tech skills that can’t be trained.

Error trapping and validation

Users, especially untrained users, can often enter invalid information. This can result in the application not being able to process the request, or potentially even error out. 

Well-developed software eloquently alerts and explains invalid data to the end user. It also prevents or handles bad entrees to avoid crashes.

We’ve all worked with programs that provide no feedback or information when they crash.  They simply do nothing or close.  That’s because the developers didn’t account for or “handle” that error.

We’ve also experienced applications that provide clear explanations for the problem. For example, “Your credit card expiration date is invalid”. 

The difference between those applications is error trapping and handling.  Error trapping requires effort, but that effort can turn an error into a user-friendly explanation.

Third party system integrations

Many organizations run multiple mission-critical software applications. To harness these systems efficiently, it’s sometimes necessary to integrate them.  Integrating multiple systems requires navigating the specifics of each application.

Most modern business applications (CRMs like Salesforce or HubSpot and ERPs like NetSuite or Acumatica) provide APIs (Application Programming Interfaces) to allow other systems to integrate with them.  These APIs are applications in themselves, and many times have details and specific instructions on how to authenticate and integrate with them.  Reviewing and understanding this documentation and then developing and testing it all takes time and effort.

Data importing

A forgotten effort in many projects. 

Importing data from legacy or other systems is often critical to the deployment of a new program, but requires:

1. the data structure of both the old and new system to be fully understood and
2. the data fields to be mapped. 

Many times, the importing of the data requires a smaller import program or script to be developed.

Regulatory requirements

Various industries require different regulatory standards for how their data is handled. 

Standards like HIPAA (Medical), PCI (financial), DFARS (Federal Defense) require development done to the highest security standards and warrant periodic security audits of the application.

QA and testing

Testing software can be an art. When done properly it can prevent difficulties down the road. 

Testing is more than just a few clicks to make sure things work when a user does what they are supposed to. Testing also involves trying to do things that the user should not do.

UAT

Before an application can be put into a production environment, the stakeholders must confirm that the program is ready for “prime time”.  This is done through a series of tests to confirm the application works as it is expected.  Many times, this requires someone from the development team to guide the testers through the process.

Launch

The most successful launches are seldom without hiccups.  Having the proper resources available to rapidly respond after launch is extremely beneficial.  Support rooms made available for users with sign in or other issues in the early stages of a launch can ease concerns for the user base and greatly improve the experience and buy in for staff.  Application monitoring software can help dev team identify problems that users may not even know are happening and correct them before they because issues.

Support

Even advanced, trained users have questions or identify hidden glitches in applications.  Having support available to the team is critical to an application’s success.  Whether it is rarely invalid data entered that creates issues, or edge cases that weren’t identified during development, QA or UAT issues are likely to arise. Having the resources available to assist, troubleshoot and resolve the issues yields better results.

Next steps

The primary steps to evaluate your need for custom software are:

1. Confirm you need custom software in the first place (as opposed to off-the-shelf options)
2. Identify why you need custom
3. Prioritize your needs and preferences
4. Understand the approach

Confirm your need for custom software

Evaluate leading SaaS or licensed off-the-shelf software for your industry or application.

Perform a thorough review of the available systems and identify if they’ll work for you.  Many of these systems allow for customization.  Be sure to consider the customization options when evaluating if the system can suit your needs.

If something off-the-shelf works for 90+% of what you need, that may be a good option.

Consider integration possibilities. If you find the off-the-shelf options don’t meet the 90+% threshold of what you need (or even if they do and you want to fill the remaining 10%), evaluate the potential for custom software that integrates with the SaaS software. Many modern platforms offer robust APIs that enable developers to efficiently interact with them.  This could reduce the overall time and cost of your solution by reducing the amount of custom development.

If you still find that you need or desire custom software:

Identify why you need custom software:

Every organization is unique and as such the reasons for pursuing custom software are also unique.  Some reasons we’ve seen:

• Niche industries not well served by SaaS or licensed software products
• Unique processes or workflow that aren’t well-handled by existing software solutions
• Multiple software systems that perform well for some departments or user groups, but are not integrated
• Competitive advantage
• Businesses that have thrived with custom software that is now becoming outdated

Prioritize your needs and preferences

1. Are you willing to dedicate resources to help manage the project or are you looking for a development firm that can take most of that off your plate?
2. Does your application have to comply with specific regulatory guidelines like HIPAA, PCI or DFARS?
3. Would a team with expertise in your field be better suited for your project or would a fresh set of eyes help differentiate you from the pack?
4. Is reducing cost worth potential obstacles with time zone or language barriers?
5. Will you need ongoing support or development?
6. Would you rather the software be developed fast but with higher costs or lower costs but slower results?
7. Would on site visits, staff shadowing or process evaluations aid in the development of your solution?

Understand the approach

Understand how the team tackling your project works and if it suits your needs and priorities:

1. How large will the development team be and what are the roles each team member will play?  Do all of the roles seem necessary?  Do they add value?
2. Understand your estimate and what is included in that estimate.  Is this for an MVP or a fully functional application with all desirable features?
3. How experienced is your team?  Do they have expertise in your field, regulatory requirements, application type, etc.?
4. What processes will your team work under?  How will you communicate?  What response level is expected?  How will you monitor progress?  How will you address concerns or problems?
5. How will your application be supported after initial release?

If you decide you need custom software, check out our about page to see if we’re a good fit for you. If you’d like to discuss, you can reach out here: