How much does custom software cost? What drives it

How much does custom software cost? The honest answer is that it depends on five main factors: the scope (what the software has to do), integrations with the systems you already use, the state of the data coming from older systems, compliance and security requirements, and what happens after delivery. The good news is that almost all of these factors can be controlled: with a well-defined problem, a small first version and a written proposal that says exactly what it includes and what it does not.

We do not publish figures in this article: a number without context hides the assumptions that actually set the price. Instead we explain what makes the cost vary, how to ask for an accurate proposal and what it should contain.

Why no serious supplier gives you a price without asking questions

"An app to manage orders" could be an improved spreadsheet for one person, or a system with several user roles, ERP integration, a customer portal and per-customer pricing rules. Both descriptions fit in the same sentence. The cost does not.

A fixed figure given after a ten-minute conversation either includes a large margin to cover what the supplier does not know, or that unknown turns up halfway through the project in the form of "scope changes". Neither is good for you.

The factors that drive the cost

1. Scope: what the software really has to do

This is the factor with the most weight. It is not measured in number of screens but in the complexity of the business rules. Some questions that determine it:

How many types of user are there, and what can each one see and do?
How many different workflows does the system support (orders, approvals, returns, invoicing)?
How many exceptions are there? "It's usually like this, but for these customers it's different" is the sentence that adds the most cost to a project.
Do you need a mobile app, offline use, multiple languages?

A typical situation: an SME wants to replace a set of spreadsheets that runs its production. The first list of requirements has thirty items. After looking at the real process, it turns out that eight of them solve most of the day-to-day problem. The others can wait for a second phase, or may never be needed.

2. Integrations with the systems you already use

Few businesses start from scratch. There is an ERP (PHC, Primavera, Sage or another), an online store, a bank, a carrier, perhaps an email marketing platform. Each integration has a cost, and that cost depends less on the number of integrations than on the quality of each one:

Does the system have a documented, stable application programming interface (API), or does the integration have to go directly into the database or through exported files?
Does data need to flow both ways, or is reading it enough?
What happens when one side is down? Is the data queued, or is it lost?

A poorly specified integration is often the biggest source of overruns.

3. Legacy data and migration

If the new software replaces another system, or a collection of spreadsheets, the old data has to move into the new system. In theory it is a copy. In practice, old data has duplicates, customers with three different records, fields used for different purposes over the years, and rules that only exist in the heads of the people who entered them.

The cost of migration depends on volume, but above all on the quality of the data and on how many different sources need to be consolidated. It is worth asking right at the start: who in the company will validate that the migrated data is correct? That validation is real work, and someone on your side has to do it.

We cover this topic in more detail in Legacy systems: signs your software is holding your business back.

4. Compliance, security and accessibility

Some requirements are not optional and have to be in scope from the start:

Data protection. If the software processes personal data about customers or employees, the GDPR requires appropriate technical and organizational measures to ensure the security of that processing (Article 32) and provides for rights such as erasure of the data (Article 17) (Regulation (EU) 2016/679, EUR-Lex). Access control, a record of who changed what, and a way to export or delete a person's data cost less if they are designed in from the beginning.
Invoicing. In Portugal, issuing invoices has its own rules, including the use of invoicing software certified by the Tax and Customs Authority (Autoridade Tributária), under Ordinance (Portaria) No. 363/2010 (gov.pt: Request certification of invoicing software). That is why, in most cases, custom software should integrate with the certified invoicing program the business already uses, instead of issuing invoices itself. This decision changes the cost considerably.
Accessibility. The European Accessibility Act (Directive (EU) 2019/882) has applied to certain products and services, including e-commerce services, since June 28, 2025, with an exception for microenterprises providing services (Directive (EU) 2019/882, EUR-Lex). It was transposed into Portuguese law by Decree-Law No. 82/2022.  If the software is used by your customers, and not only internally, check whether these rules apply.

5. Users, volume and availability

An internal tool used by five people is different from a portal used by thousands of customers at any hour. The volume of data, the number of simultaneous users and the cost of the system being down for an hour determine the infrastructure, monitoring and testing required. If half a day of downtime is an inconvenience, the solution can be simple. If half a day of downtime means lost orders, the investment in reliability has to be in the budget.

6. What happens after delivery

The cost of software does not end on the day it is delivered. There is hosting, third-party service licenses, security updates and the improvements that will come up with use. In a proposal, look for clear answers to these questions:

Where is the system hosted, and in whose name?
Who owns the code, and where is it kept?
What documentation and knowledge transfer are included, so that your team, or another supplier, can carry on the work?
What recurring third-party costs are there (hosting, email delivery, maps, payments)?

7. Uncertainty

When the questions above do not have answers yet, the sensible thing is to start with a short discovery phase that has a concrete outcome: a defined scope, a proposed architecture and identified risks. Only then is the price of the build fixed. It looks like an extra step, but it is what stops you paying for the uncertainty twice.

How to control the cost

Start with the problem, not the feature list. "Cut the time it takes to prepare orders" guides decisions better than a list of forty screens.
Build a small first version. Build the minimum that solves the main problem and put it in the hands of real users. What you learn will change the priorities for the next phase, and learning from a small version is cheaper.
Buy what is generic, build what sets you apart. Accounting, invoicing and email already exist and work. Custom software should focus on what is specific to your business.
Have one person with decision-making power. Decisions that wait weeks for a meeting cost money, even when nobody is writing code.
Prefer fixed scope in phases. Iterations with scope and price agreed before they start give you checkpoints: at the end of each one, you decide whether to continue, change direction or stop.

How to get an accurate proposal

You do not need a formal specification document. Prepare the following:

The problem, in a few sentences. What goes wrong today, and what it costs in time, errors or missed opportunities.
The current process. How the work is done today, including the spreadsheets and the manual steps. Real examples (without personal data) help a lot.
The systems involved. Which ERP, which online store, which other tools, and whether they have an API or data export.
Approximate volumes. Number of users, orders per month, records to migrate.
Deadlines and the reason for them. "By March" helps little. "By March, because that is when the peak season starts" helps a lot.
An approximate budget. Sharing a range does not put you at a disadvantage. It lets the supplier propose the best solution within that range, instead of guessing.
Who decides. And who will validate the work on the company's side.

What a good proposal should contain

A good software development proposal lets you compare suppliers and, later, confirm that you got what you paid for. It should include:

Scope and exclusions. What is included and, just as important, what is not.
Assumptions. For example: "the ERP provides an API with access to orders" or "the data to migrate is supplied in a single file". If an assumption fails, everyone knows from the outset what changes.
Phasing and deliverables. What is delivered in each phase and how you can try the work before the end.
Timelines. Per phase, with the dependencies on your side (access, sign-offs, data) identified.
Price and payment terms. Tied to phases or deliverables, not to open-ended hours.
How changes are handled. What happens when a new request comes up mid-project.
Acceptance criteria. How it is decided that a phase is complete.
Ownership of the code and data. Who owns the code, where it is kept and when it is handed over to you.
Recurring costs and responsibilities after delivery. Hosting, third-party licenses, documentation and knowledge transfer.
Known risks. A supplier that identifies no risks either has not looked carefully or is not telling you everything.

Warning signs

Be wary of proposals with a vague scope ("development of a management platform"), no exclusions, no assumptions, full payment up front, or where the code stays with the supplier. And be wary of a price that arrives before anyone has asked you hard questions about your business.

Next step: a written proposal, with no commitment

This is how we work in MVP & Product Development: scope cut down to what proves value, iterations with scope and price agreed before they start, a working version in your hands early on, and code that is yours.

Talk to us and describe in a few sentences what you want to build, fix or automate. We reply within one business day with questions and a first honest opinion. After a short conversation, you receive a written proposal with scope, approach, timelines and price, with no commitment.

What drives the cost of custom software (and how to control it)