What drives the cost of custom software, and how to keep it under control

Two companies ask for "a simple portal for our clients" and receive quotes that are very far apart. Usually both vendors are being honest. They are pricing different things, because the request leaves most of the real decisions open: who uses the portal, which systems it talks to, what happens when something goes wrong.

In custom software, cost is driven less by the number of screens and more by the number of rules, roles and connections behind them. A study by McKinsey and the University of Oxford of more than 5,400 IT projects found that large projects ran on average 45 percent over budget while delivering 56 percent less value than predicted. Much of that gap comes from things nobody pinned down at the start.

Below are the cost drivers we see most often, and the working habits that keep them under control.

The main cost drivers

Scope and number of roles

Each type of user adds more than a login. A system used by one group (for example, office staff) is much simpler than one used by staff, managers, customers, suppliers and auditors, each seeing different data and allowed different actions. Every role multiplies permission rules, screens, notifications and test cases. When you list your users, also list what each of them must not see.

Integrations

Connecting to an accounting system, an ERP, a bank, a courier, a tax authority or a payment provider is often the largest single item in a project. The effort depends on the other side: is there a documented API, a test environment, a stable data format, someone who answers questions? A connection to a well-documented service can take days. A connection to an old system that only exports files once a night can take weeks, and it will need attention every time that system changes.

Data migration

Moving data from spreadsheets or an old system sounds like copy and paste. In practice it means removing duplicates, filling missing fields, mapping old codes to new ones and deciding what to do with records that do not fit anywhere. Migration is also where business people must spend the most time, because only they know whether "ABC SRL" and "A.B.C. S.R.L." are the same customer.

Quality and security requirements

A tool used by five colleagues and a system that handles payments or personal data are different products, even if the screens look alike. Requirements for availability, response time, audit trails, backups, access control and data protection add design, testing and documentation work. Published standards help make this concrete. ISO/IEC 25010 describes product quality characteristics such as reliability, security and maintainability, and the OWASP Application Security Verification Standard gives a list of security requirements at different levels of rigour. Choosing the level that fits your actual risk avoids paying for too little or too much.

Platforms

A web application that works well in desktop and mobile browsers is one product. Native apps for iOS and Android, an offline mode for warehouse staff, or support for old browsers in a client's network each add development, testing and release work. Before committing to the app stores, check whether a responsive web application covers the real need.

Team model

An in-house team, a freelancer, an outsourced team or a mix: each has a different cost profile. A lower daily cost does not always mean a lower total cost if coordination, rework and handovers take longer. What matters is who makes decisions, how quickly questions get answered, and how knowledge stays with your company if people change.

How to keep cost under control

Start with a minimum viable product

Define the smallest version that delivers real value to real users, and build that first. For a client portal this might be login, order status and document download, without chat, analytics or a mobile app. An MVP is not a demo: people should be able to use it in their daily work. Its job is to confirm what matters before you spend money on what might matter.

Deliver in stages

Split the work into short stages, each ending with working software you can try. The principle from the Agile Manifesto still holds: deliver working software frequently, from a couple of weeks to a couple of months. Each stage is a natural point to review spending, change priorities or stop. A long project with a single delivery at the end gives you none of these options.

Write clear acceptance criteria

For each feature, agree in writing how you will know it is done. "Invoices can be exported" is vague. "An accountant can export all invoices for a selected month to a file that the accounting system imports without manual changes" can be tested. Clear criteria reduce arguments, rework and the slow cost of features that stay "almost finished" for months.

Manage change on purpose

Requirements will change, and they should when you learn something new. The problem is unmanaged change. Keep a simple rule: every new request gets a short written description, an estimate and a decision about what moves later to make room for it. This keeps the budget visible and stops the first version from growing quietly.

Look at the total cost of ownership

The first release is only part of the cost. Over the life of a system you also pay for:

• hosting, domains, certificates and backups
• third-party licences and API fees
• security updates and upgrades of the libraries the software depends on
• monitoring, and support when something breaks
• small changes as your processes and the law change
• the time your own staff spend administering the system

Shortcuts taken to hit an early date also have a price. Martin Fowler describes this as technical debt: messy internal code makes every future change slower, like interest on a loan. Some debt is a reasonable choice for an MVP, as long as it is a conscious decision and you pay it down in the next stages.

A checklist before you ask for a quote

• List the user roles and what each one can see and do.
• List every system the software must connect to, with a contact person for each.
• Describe the data you have today and where it lives.
• Note legal and security requirements: personal data, e-invoicing, audit, retention.
• Decide which platforms you need now and which can wait.
• Define what the first usable version must include, and what it must not.

A vendor who receives this list can estimate from facts instead of assumptions, and you can compare quotes on the same basis.

How NOWANI TECH can help

We help companies turn a rough idea into a clear scope, a first usable version and a staged plan with acceptance criteria, before large spending starts. We build in short stages and plan hosting, maintenance and support from the first day, so the full cost is visible early. If you are preparing a project and want a second opinion on scope or budget, get in touch.