How much custom software costs and what drives it

The price of custom software depends on what has to be built, on what already exists and on how it will be maintained afterwards. That is why it cannot be given properly before the problem is scoped: whoever gives you a fixed number before knowing what is in and what is out is placing a bet, and someone ends up paying for it.

What you can know from the start is what it depends on, how a serious estimate is built and how to compare two proposals. That is what this guide covers.

They do not weigh the same in every project, but it is worth going through them one by one before asking for a quote.

Scope

How many processes, screens and business rules are included, and which are left out. What is left out, written down, is also part of the price.

What already exists

Systems in use, data in spreadsheets and programs you have to live alongside. Migrating the data is the part of the work that is most underestimated.

Integrations

Every connection to invoicing, the till, email, banking or another program is work in itself and a point that can change when the other program is updated.

Who uses it

How many different profiles there are, what each one can do and from which devices it is used.

Quality required

Tests, documentation, security and traceability. Building to be maintained costs more at the start and considerably less afterwards.

Uncertainty

How much is known about the problem. The less there is, the more it pays to reduce it in a preliminary phase before committing to a price.

After delivery

Fixing faults, updates and changes. A system with no maintenance ends up worse than the spreadsheet it replaced.

A serious estimate is built in a particular order. Skipping a step does not speed it up: it makes it less reliable.

• The problem, the scope and the priorities are written down: what is in, what is out and in what order.
• Unless the work is simple and standard, it starts with a short definition phase that reduces uncertainty.
• The estimate is made on that scope, with the assumptions in plain view.
• The work is delivered in phases, each with an agreed objective, deliverable and date.
• Changes with a significant impact are estimated and approved separately, instead of slipping into the project.

There is no good way in the abstract: each one fits a different level of certainty.

Fixed price

When the scope is clear and will not change. It works if the price comes after the scope is set; if it comes before, someone takes on the risk without knowing it.

By the hour

When there is a lot of uncertainty or you are exploring. It gives flexibility and requires trust and follow-up.

By milestone

When the project is split into phases with clear deliverables. It lets you stop or change course between one phase and the next.

Monthly fee

For the ongoing maintenance and evolution of a system that is already running.

• It gives a price without saying what is in and what is out.
• It promises a fixed deadline before knowing the problem.
• It says “all included” without a list of what that includes.
• It does not split the work into reviewable phases, so you only see the result at the end.
• It does not say who owns the code or what documentation is delivered.
• It says nothing about what happens after delivery: maintenance, support, changes.
• No specific person answers for the project.

• If a tool that already exists covers the process with small compromises, it is almost always better and cheaper.
• If the process still changes every month, building it now fixes a mistake in place.
• If nobody is going to maintain it, the system will end up worse than what it replaces.

The first reasonable step is a preliminary analysis: a short phase, with its scope, its deliverable and its amount agreed in writing before it starts. It turns the problem into a scope, a plan and an estimate that hold up, and the document is yours even if someone else builds it afterwards.

Consulting and discovery

What it is and what it leaves decided

How much does custom software cost?

It depends on the scope, on what already exists and on how it will be maintained, which is why no figure is given before the problem is scoped. What you can ask for before deciding is a proposal that says what is in, what is out, in which phases it is delivered and how it is estimated.

Why are two quotes for the same thing so different?

Because it is almost never the same thing. What changes is what each one includes: tests, documentation, security, data migration, maintenance and ownership of the code. Compare what each proposal covers first; the amount comes after.

Can I ask for a fixed price?

Yes, when the scope is clear and stable. If there is still significant uncertainty, the honest thing is a preliminary phase to reduce it and set the price afterwards: a fixed price with no basis usually ends in changes to the scope.

Can we start with something small?

Yes, and it is usually the most prudent option: a first, bounded phase that works from start to finish and can be extended later, instead of one large project all at once. It reduces risk and lets you decide with something already working.

What happens to the cost when the project ends?

A system in use needs maintenance: fixes, security updates and changes. It is worth discussing it before you start and writing down the conditions: a system nobody looks after degrades and ends up costing more than it saved.

When the spreadsheet stops being enough

A four-step ladder to decide when to move from Excel or a spreadsheet to a tool, an automation or custom software.

Custom software examples for small businesses

What custom software usually looks like in a small business, examples by type of business and when a ready-made tool is enough.