What drives the cost of custom software

Ask three suppliers what a customer portal costs and you will get three numbers that are not comparable, because each one is quietly pricing a different piece of software. That is frustrating, but it is not evasion. Until someone writes down who uses the software, what it connects to and what has to be true before it goes live, there is no single answer to give. This article explains what actually moves the number, so you can read an estimate critically and change the parts you control.

Why is scope the main cost driver?

Almost all custom software cost is people time. Frameworks, databases and cloud services are real expenses but small ones next to the weeks of skilled work that go into design, development, testing and release. So anything that adds weeks adds cost, and the largest single source of added weeks is scope.

Scope is not a feature count. It is the number of distinct things the software has to do correctly, including all the cases nobody mentions in the first meeting.

User roles multiply everything

Every additional role adds its own screens, its own permissions, its own edge cases and its own tests. A tool used by one internal team is a different size of project from the same tool opened up to customers, suppliers and an administrator, even when the underlying data is identical.

Before pricing anything, list the roles and what each one can see and do. Cutting a role from the first release is one of the largest and least painful savings available.

Undefined decisions are expensive

Every question left open in the brief resurfaces mid-build, when answering it is far more disruptive. PMI research on requirements management found that inaccurate requirements management is the primary cause of failure in 47% of unsuccessful projects, and that 5.1% of every dollar spent on projects and programs is wasted because of poor requirements, which is US$51 million for every US$1 billion spent.

A week spent on the brief before anyone quotes is the cheapest week in the project. Our guide to writing a requirements brief a development partner can use sets out the structure.

What do integrations and data migration add?

These are the two items most often missing from a first budget and most often responsible for an overrun.

An integration is a connection that lets your new software read or write data in an existing system such as an ERP, CRM or document store. The cost depends on whether the system has a documented, modern API, whether your license includes API access, whether someone can grant credentials, and how good the data is once you get it. A well-documented integration is routine work. An undocumented one, or a system where a vendor controls access, can take longer than the feature it supports.

The scale of the problem is not unusual. The 2025 MuleSoft Connectivity Benchmark Report found that the average enterprise manages 897 applications with only 29% of them integrated, and that IT teams spend 39% of their time building custom integrations and automations.

Data migration is moving existing records into the new system. Its cost is driven by data quality, not volume. Duplicate customers, inconsistent product codes, dates in three formats and free-text fields holding structured information all have to be found, cleaned and reconciled, usually with someone from the business deciding what is correct. Export a sample early and look at it honestly. It is the single best predictor of whether migration will be a small task or a project of its own.

How do security and compliance requirements change the estimate?

Every application needs sound basics: authentication, role-based access, encryption in transit and at rest, backups, logging. Those are not optional and are usually included.

Costs rise when specific obligations apply. Single sign-on against your identity provider, detailed audit trails showing who changed what and when, data residency in a particular country, retention and deletion rules, penetration testing, or evidence packs for a customer security review are each real work. Handling regulated data such as health or payment information raises the bar further.

None of this is a reason to avoid custom software. It is a reason to state the requirements before the estimate rather than discovering them during a customer security questionnaire three weeks before launch, when the fix is a redesign.

What do design depth and platform choice cost?

Design cost scales with how much of the product real people touch. An internal dashboard for twelve analysts needs to be clear and consistent, nothing more. A portal your customers use unaided needs research, tested flows, accessible components, empty and error states, and a look that fits your brand. Both are legitimate. Choosing the second by default for an internal tool is a common way to spend money without gaining anything.

Platform choice matters more than framework choice:

• Responsive web is usually the cheapest route to every device, and it is enough for most business software.
• Native mobile apps cost substantially more, because you are often building and maintaining two applications plus their release processes and store approvals. Justify them with something real, such as offline working, camera or barcode use, or push notifications field staff rely on.
• Offline capability is a genuine cost driver wherever it appears, because syncing data and resolving conflicts is difficult work.

Illustrative example: Consider an accounting firm of about 90 people scoping a client portal. The first conversation describes a simple place for clients to upload documents, and the first rough figure reflects that. Then the detail arrives: clients, partners, an admin role and a read-only reviewer, single sign-on for staff, a two-way connection to the practice management system, migration of six years of files with inconsistent client references, a retention rule tied to statutory periods, and an audit trail the firm needs for its own quality reviews. None of those requests is unreasonable. Together they make the project several times the size of the one first described. The lesson is not that the portal costs too much. It is that the first number was priced against a different portal.

Why does testing appear in the budget?

Testing is often the first item a buyer tries to trim, and it is the one that reliably costs more later. It covers automated tests that catch breakages when the code changes, testing against your real business scenarios rather than ideal ones, and user acceptance testing by the people who will do the work.

The reason to fund it is economic rather than moral. CISQ estimated that the cost of poor software quality in the US had grown to $2.41 trillion, with accumulated technical debt, meaning the cost of reworking suboptimal software, at approximately $1.52 trillion. Defects found by a user in production cost far more than defects found in a test, because they carry an incident, a workaround, lost trust and a fix made under pressure.

There is also a staffing point worth knowing when you read a rate card. The US Bureau of Labor Statistics puts the median annual wage for software developers at $135,980 and for software quality assurance analysts and testers at $104,300, both in May 2025. Testing is not the expensive part of the team.

What does custom software cost after it launches?

The first release starts the spending, it does not end it. Plan for:

1. Hosting and third-party services. Cloud infrastructure on AWS or Azure, plus email delivery, document storage, payment processing and any AI model usage.
2. Security maintenance. Patching, credential rotation, access reviews and responding to vulnerabilities in the libraries your software depends on.
3. Dependency upgrades. Frameworks and languages move. Software left on old versions becomes progressively harder and more expensive to change.
4. Support. Someone answers questions, investigates problems and fixes what breaks.
5. Change. Processes, prices, regulations and integrations shift, and the software has to follow.

Running costs dominate over a long enough period. The US Government Accountability Office reports that federal agencies spend more than $100 billion a year on IT and cyber-related investments and typically report spending about 80 percent of that on operations and maintenance of existing IT. A federal portfolio is not a 150-person company, and the exact share will differ for you, but the direction holds: the build is rarely the largest part of the lifetime bill. What happens when maintenance goes unfunded is covered in technical debt in business systems.

Do AI coding tools make custom software cheaper?

They change part of the picture, and the published evidence is more mixed than the marketing.

On the positive side, GitHub's controlled experiment found that developers using Copilot completed an HTTP server task in JavaScript 55% faster than a control group, across 95 professional developers. Against that, a 2025 METR study of 16 experienced open source developers working on large, familiar codebases found they took 19% longer with AI tools, despite expecting to be roughly 24% faster.

Developers themselves are measured about it. In the Stack Overflow 2025 Developer Survey, 84% were using or planning to use AI tools, yet 46% distrusted the accuracy of the output, 66% named solutions that are almost right but not quite as their biggest frustration, and 45% said debugging AI-generated code is more time-consuming. Google's 2025 DORA report found 90% of respondents using AI at work and about 30% reporting little or no trust in AI-generated code, and summarizes the effect as amplifying what a team already is rather than fixing it.

The practical reading for a buyer: AI tools can compress well-defined implementation work, particularly on new code. They do not reduce the cost of deciding what to build, reviewing and securing the result, integrating with awkward systems, or maintaining the software for years. Treat claimed savings as a question to ask, not a discount to assume, and expect the gain to show up as more depth for the same budget at least as often as a lower number.

How should you structure the contract, and where can you save?

Fixed scope or time and materials

A common middle path works well: buy discovery and design at a fixed price, then use that output to fix the price of the build, or run the build on time and materials with an agreed cap and a written definition of done.

Reducing cost without cutting quality

1. Write the brief before you ask for a price. It is the cheapest lever and the one that also improves the estimates you receive.
2. Cut roles and edge cases, not testing or security. Removing an audience shrinks the project. Removing quality moves the cost later.
3. Ship the core workflow first and let real usage decide the second release.
4. Integrate rather than rebuild. If the data already lives in your ERP or CRM, connect to it. See build, buy or integrate.
5. Use proven components for authentication, payments and email rather than building them.
6. Check whether a platform app would do. For internal tools the answer is often yes, as off-the-shelf, no-code or custom explains.
7. Clean the data before migration, using business staff who know what is correct.
8. Agree a decision owner and a response time. Waiting for answers is billable and invisible.
9. Limit revision rounds by agreement, two per deliverable is normal, so feedback stays deliberate.

How Kastling approaches cost

Kastling is an AI solutions and implementation partner, and pricing depends entirely on the scope agreed for your engagement, so we do not publish rates or ranges. What we do commit to is arriving at the number the same way every time.

An engagement starts with a free discovery call. Where the work is broad or the current process is unclear, a separately scoped, paid audit establishes what happens today and where time and money are going. A well-defined brief can move straight to a scoped proposal. Before development starts we agree scope, dependencies, milestones, how success will be measured, and who owns the data, the code and the cloud accounts.

Custom Solutions covers internal tools, dashboards, customer or supplier portals and web or mobile apps, with or without AI. Infrastructure and usage charges are treated as their own cost area rather than hidden inside a build price, and ongoing maintenance is optional under a separate agreement that states what is included.