Key takeaways
- Scope, not technology, is the main cost driver: each additional user role multiplies screens, permissions and test cases.
- Integrations and data migration are the two items most often missing or badly underestimated in a first budget.
- Testing is not an optional line item. You pay for it during the project or in production, where it costs more.
- Budget every year after launch for hosting, security updates, dependency upgrades, support and small improvements.
- AI coding tools can speed up parts of development, but the published evidence is mixed and they do not reduce the cost of requirements, review, security or maintenance.
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. For a company of roughly 20 to 200 people commissioning a first internal tool or portal, this article explains what actually moves the number, so you can read an estimate critically and change the parts you control.
What factors affect the cost of custom software development?
Eight factors drive the difference between one estimate and another: user roles, integrations, data migration, security and compliance, design depth, platform, testing and life after launch. The table shows why each one adds cost and what you control.
| Factor | Why it adds cost | What you control |
|---|---|---|
| User roles | Each role adds screens, permissions, edge cases and tests | Which audiences the first release serves |
| Integrations | Each connection depends on API access, credentials and data quality in another system | Which systems the first release must connect to |
| Data migration | Duplicates, inconsistent codes and free-text fields have to be cleaned and reconciled | How much history moves, and who decides what is correct |
| Security and compliance | Single sign-on, audit trails, data residency and retention rules are each real work | Stating the requirements before the estimate |
| Design depth | Customer-facing software needs research, tested flows and accessible components | Whether the tool is internal or public |
| Platform | Native mobile apps add separate builds and store approvals; offline working adds sync work | Responsive web unless something real demands more |
| Testing | Automated, scenario and acceptance testing take time, and skipping them moves cost into production | Funding it in the plan, not trimming it |
| Life after launch | Hosting, patching, upgrades, support and change continue for years | The maintenance agreement and who carries each task |
Why is scope the main cost driver?
Most of the cost of custom software 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?
Integrations and data migration are easy to miss in a first budget and a common source of overruns.
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 gap is not unusual: MuleSoft's 2025 benchmark found that most enterprise applications are not integrated, and our guide to build, buy or integrate sets out the figures.
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 usually cost 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:
- Hosting and third-party services. Cloud infrastructure on AWS or Azure, plus email delivery, document storage, payment processing and any AI model usage.
- Security maintenance. Patching, credential rotation, access reviews and responding to vulnerabilities in the libraries your software depends on.
- Dependency upgrades. Frameworks and languages move. Software left on old versions becomes progressively harder and more expensive to change.
- Support. Someone answers questions, investigates problems and fixes what breaks.
- 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?
AI coding tools change part of the cost picture, and the published evidence is mixed. They can compress well-defined implementation work, but 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 a supplier, not a discount to assume; the studies from GitHub, METR, Stack Overflow and Google are summarized in build, buy or integrate.
Why do custom software quotes vary so much between suppliers?
Quotes vary because each supplier is pricing a different scope. One assumes two user roles and a spreadsheet import, while another assumes five roles, a live integration and a migration of ten years of records. Put the same five items in the brief for every supplier, and the quotes become comparable:
- The user roles, and what each can see and do.
- The systems the software must connect to, with the direction data moves.
- The volume and condition of the data to migrate.
- The security and compliance requirements, including single sign-on and audit trails.
- The support hours and response times expected after launch.
Then ask each supplier for a feature-by-feature breakdown against that brief, with exclusions named.
How should you structure the contract, and where can you save?
Fixed scope or time and materials
| Fixed scope | Time and materials | |
|---|---|---|
| Works when | The scope is genuinely settled | Discovery is ongoing or priorities move |
| Who carries delivery risk | The supplier, priced into the number | You, with visibility as you go |
| Changes | Formal change requests, slower | Reprioritize within the next cycle |
| Main failure mode | Disputes over what was included | Drift without a cap or clear milestones |
| Good practice | Detailed brief, named exclusions | Agreed cap, fixed cadence, regular demos |
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
- Write the brief before you ask for a price. It is the cheapest lever and the one that also improves the estimates you receive.
- Cut roles and edge cases, not testing or security. Removing an audience shrinks the project. Removing quality moves the cost later.
- Ship the core workflow first and let real usage decide the second release.
- Integrate rather than rebuild. If the data already lives in your ERP or CRM, connect to it. See build, buy or integrate.
- Use proven components for authentication, payments and email rather than building them.
- Check whether a platform app would do. For internal tools the answer is often yes, as off-the-shelf, no-code or custom explains.
- Clean the data before migration, using business staff who know what is correct.
- Agree a decision owner and a response time. Waiting for answers is billable and invisible.
- 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.
Build, buy or integrate decision tool
Eight questions about one process. Get a recommendation to build, buy or integrate, the reasons behind it and what to check next.
Questions
How long does it take to build custom software?
Duration follows the same drivers as cost: the number of user roles, the integrations, the amount of data to migrate and how quickly your team answers questions. A narrow first release for one workflow takes less time than a broad one, and a supplier should give you a schedule with milestones against a written brief rather than a single date. Ask what the schedule assumes about your own response times.
What should we budget each year after launch?
Plan for hosting and third-party services, security patching, dependency upgrades, user support and a modest allowance for changes, because business processes keep moving. Set the figure from your own architecture rather than a rule of thumb, and agree who carries each responsibility before the project ends. Software with no maintenance budget quietly becomes a risk rather than an asset.
Is a fixed price safer than time and materials?
A fixed price transfers delivery risk to the supplier, and the supplier prices that risk into the number. It works well when the scope is genuinely settled and badly when it is not, because every change becomes a negotiation. Many engagements do better with a fixed-price discovery and design stage, then time and materials with an agreed cap for the build.
Does building on the cloud make software more expensive?
It moves cost from a large up-front purchase to a monthly bill you can size to actual use. For most business applications the running cost is modest compared with the people cost of building and maintaining the software. The risk is not the base price, it is unmonitored usage, so agree who owns the account and who watches the bill.
Can we start smaller to reduce the initial cost?
Almost always, and it usually improves the outcome as well as the budget. Pick the single workflow that carries the most pain, release it to real users, then let their behavior decide what comes next. A narrower first release also shortens the feedback loop, which is where most rework is avoided.
Sources
- US Bureau of Labor Statistics: Software Developers, Quality Assurance Analysts, and Testers
- US GAO: Agencies Need to Plan for Modernizing Critical Decades-Old Legacy Systems (GAO-25-107795)
- CISQ: The Cost of Poor Software Quality in the US, a 2022 Report
- PMI: Requirements Management, A Core Competency for Project and Program Success
- Salesforce: 2025 MuleSoft Connectivity Benchmark Report insights