What custom software costs

The same words, a factor of ten

A "client portal" can mean a read-only area where customers find their invoices. It can also mean a platform with role-based rights, electronic signature, payment and writing back to the management system. Same word, entirely unrelated work.

That is why no serious supplier publishes a price list. It is not secrecy: a price list would assume the word describes the work, which it never does.

A supplier who quotes before understanding the need is doing one of two things: selling a disguised standard product, or planning to make it up in change requests. Both end badly, and the client finds out at the worst moment.

Proper framing, however, must produce a firm range before the first line of code. If nobody can give you one after two or three working sessions, take it as a signal.

The special case is the real unit of cost

The factor that moves a budget most is neither the number of screens nor the number of users. It is the number of special cases.

Take two companies asking for the same order-tracking tool. The first applies the same terms to all its customers. The second has different terms depending on the customer, the volume ordered, the season and how long the relationship has lasted. The two tools have the same screens. They do not have remotely the same price.

The reason is simple: a special case does not add, it combines. It has to be understood, written, tested, then checked for compatibility with all the others. That cross-checking is what costs, and it grows far faster than the number of cases.

Those special cases already exist at your company, and they work, because one person knows them and applies them. The project consists precisely of getting them out of that person's head, and it is the part nobody prices in the first meeting.

So the right framing question is not "how many features?" but "how many situations do your teams handle by hand today, because the general rule does not apply?". That answer prices the project.

What separates a 3,000-euro project from a 15,000-euro one

Start with what does not separate them: the amount of software. A 3,000-euro tool can be complete, used all day by a whole team, and have as many screens as a 15,000-euro one. The gap is not visible in what you use.

It sits in three places, all invisible from the interface.

• The connections. Plugging into a common tool that exposes a documented interface built for the purpose takes days. Plugging into an older system, or an internal tool never designed to talk to anything, means inventing the path, testing it and then monitoring it.
• How much of the process has to be invented. If your way of working resembles that of other companies in your field, the path is known and builds quickly. If it is your own, and it is often what makes you valuable, it has to be understood, written down, then translated. That is shared thinking time, not development time.
• The number of special cases, for the reasons seen above: they do not add up, they combine.

Two examples settle this better than a price grid. A job-tracking tool used by eight people, with mobile entry, photos and a monthly export: if the rule is the same for everyone and nothing has to talk to another system, it builds at the low end of the range.

The same tool, in a company whose billing follows scales of its own, which has to write back into an old management system, and where three profiles have different rights: same interface, same screens, same comfort for the user, and several times the budget.

That is why a quote is not read by its number of features. It is read on those three lines, and it is up to you to describe them in the first meeting, because you are the only one who knows them.

Beyond that the reasoning does not change, it changes scale. A 60,000-euro platform does not have twenty times more screens than a 3,000-euro tool: it has external users, security obligations, several connected systems and rules riddled with special cases.

Orders of magnitude by project type

The ranges below are averages, and that word matters. They have no limit at either end: a very focused scope costs less, a multi-site platform costs a great deal more. Maintenance is excluded.

• A custom business tool, whatever it does: between 3,000 and 15,000 euros on average.
• A client portal with authentication, documents and tracking: the same range.
• An AI agent in production, connections included: the same range again.
• An automated processing pipeline, images or documents: from 3,000 to 5,000 euros, plus a usage cost by volume processed.
• A product configurator, which needs a catalogue and visuals: between 6,000 and 25,000 euros on average.

These figures must be read the right way round. The same word can describe a 4,000-euro project and a 100,000-euro one, depending on the number of connected systems, external users and special cases. These are not different suppliers: they are two unrelated projects.

One useful marker, though: the most profitable projects are almost never the most expensive. A focused tool goes live while the big project is still being framed, and it starts saving time immediately.

The cost of year three

Count between 10 and 20% of the initial budget a year: security updates, adapting to changes in connected systems, fixes, small requests. That line is not optional. Ignoring it only defers it, and it is then paid all at once, for more.

On top come operating costs: hosting, usage-billed services, backups. On a classic internal tool they stay modest. On a pipeline consuming an engine by volume, they become the main line from year two.

So the question when comparing two quotes is not "what does the project cost", but "what does this tool cost in year three, all in". That is the number that decides, and it often reorders the ranking of proposals.

A sound maintenance contract states three things: what is included, the response time for a blocking fault, and what happens to the code if you change supplier. Those three points are negotiated before signature, never after.

The three levers that genuinely work

Reducing the initial scope is the only lever that degrades nothing. Deliver what is used daily first, put it into production, watch. Half the features requested at the outset are never asked for again once the tool is live.

Accept conventions where they do not set you apart. A standard table, a classic form, an export in the expected format: save the design effort for the places that make your difference.

Prepare your data and your rules. A clean reference base, written exceptions and someone able to decide: that is the difference between a project that moves and one that waits. Nobody can do that work for you, and it often determines the final budget.

What to write before asking for quotes: how to write a specification for custom software

Reading a quote in five points

A good quote is recognisable from simple details.

• It separates framing, building, connections, go-live and annual maintenance, with an amount for each.
• It names the systems the tool has to talk to, and how it will talk to them.
• It states what is explicitly out of scope. A quote with no exclusions has not been thought through.
• It plans a production release before the end of the project, not on the last day.
• It says who owns the code and where it is hosted.

If two proposals differ sharply on those five points, they are not pricing the same project, and comparing their totals is meaningless. Bring them to the same format before deciding.