What drives the cost of custom software, and how to keep it in check

Two companies ask for "a simple portal for our clients" and get quotes that are miles apart. In most cases neither vendor is being dishonest. They are pricing different things, because the request leaves most of the real decisions open: who will use the portal, which systems it connects to, what happens when something fails.

In custom software, cost depends less on how many screens there are and more on how many rules, roles and connections sit behind them. A study by McKinsey and the University of Oxford covering 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. A large part of that gap comes from things nobody defined at the start.

Below are the cost drivers we come across most often, and the working habits that keep them in check.

The main cost drivers

Scope and number of roles

Every type of user adds more than a login screen. A system used by a single group (office staff, for example) is far simpler than one used by staff, managers, customers, suppliers and auditors, each seeing different data and allowed different actions. Each role multiplies the permission rules, screens, notifications and test cases. When you list your users, also write down 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 biggest 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 exports files only once a night can take weeks, and it will need attention whenever that system changes.

Data migration

Moving data out of spreadsheets or an old system sounds like copy and paste. In reality it means removing duplicates, filling in missing fields, mapping old codes to new ones and deciding what to do with records that fit nowhere. Migration is also where business people have to invest the most time, because only they know whether "ABC Ltd" and "A.B.C. Limited" 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 when the screens look similar. 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 provides a list of security requirements at different levels of rigour. Picking the level that matches your actual risk keeps you from paying for too little or too much.

Platforms

A web application that runs 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 already covers the real need.

Team model

An in-house team, a freelancer, an outsourced team or a combination: each comes with a different cost profile. A lower daily rate does not always lead to a lower total cost if coordination, rework and handovers take longer. What counts is who makes decisions, how fast questions get answered, and how knowledge stays inside your company when people change.

How to keep cost in check

Start with a minimum viable product

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

Deliver in stages

Break the work into short stages, each ending with working software you can try out. The principle from the Agile Manifesto still applies: deliver working software frequently, from a couple of weeks to a couple of months. Every stage is a natural moment to review spending, shift 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 finished. "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 cut down on arguments, rework and the slow cost of features that remain "almost finished" for months.

Manage change on purpose

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

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 relies on
• monitoring, and support when something breaks
• small changes as your processes and the law change
• the time your own staff spend running the system

Shortcuts taken to meet an early date also come at a price. Martin Fowler describes this as technical debt: messy internal code slows down every future change, like interest on a loan. Some debt is a sensible choice for an MVP, provided it is a conscious decision and you pay it back in the following stages.

A checklist before you ask for a quote

• List the user roles and what each of them can see and do.
• List every system the software has to connect to, with a contact person for each.
• Describe the data you have today and where it is kept.
• Note the 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 has to include, and what it must leave out.

A vendor who receives this list can estimate from facts rather than assumptions, and you can compare quotes on equal terms.

How MTV GROUP can help

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