“What does software like this cost?” is a fair question. It just has the same answer as “What does a house cost?”: it depends on what goes into it. The difference is that you can count the rooms of a house. In software, the rooms are your workflows, and at the start they are rarely fully known.

This guide helps you keep the total cost in view: what comes on top of development, where you can save and how to compare quotes.

What determines the price

The price is determined by what the software has to do: how many workflows and departments are involved, how many rules of your own there are, which systems it exchanges data with and which old data comes along. How a provider turns that into an estimate, and why small things are often more work than expected, is described in detail in the guide How a software estimate is made.

When it comes to cost, though, more counts than development. If you only compare the price of the first version, you are comparing the smaller part.

What is often forgotten

The price of the first version is only part of the bill. These costs come on top and belong in the comparison from the start:

  • Operation. The software runs on a server, in the cloud or on your premises. That costs money continuously, even if nobody changes anything.
  • Maintenance. Operating systems, browsers and connected systems change. For the software to keep working, it has to be looked after. What that involves is described in the guide Software after launch.
  • Changes. After launch, employees notice things that would be better done differently. That is a good thing, but it is work. Plan for it from the start.
  • Onboarding. Employees need time to switch over. That time is missing from daily business, and the better the software fits the workflow, the less of it is needed.
  • Your own time. No software turns out well without people from the business who answer questions, look at interim versions and test. That time appears in no quote.

How to lower the costs

The most effective levers are not in the hourly rate, but in how the project is scoped.

Start small. Instead of mapping the whole company at once, begin with the area where things jam the most. The benefit comes sooner, and what you learn along the way makes the next areas cheaper.

Go area by area. Each area is a separate, manageable engagement with its own estimate. After each area you can decide whether and how to continue.

Do not build everything from scratch. Sign-in, permissions, documents, collaboration: almost every application needs them, and they do not have to be developed anew every time. That is why, as a rule, we develop on ElbDesk, the foundation we build on. The effort then goes into your workflows, not into things every piece of software needs anyway.

Keep what works. An existing system that does its job does not have to be replaced. Often it is enough to connect it and add only what is missing.

Question the special routes. Not every exception has to go into the software. Sometimes it is cheaper to simplify a rare special route in the workflow than to map it.

For some projects there are also grants. Which programmes exist is described in the guide Funding for digitalisation.

Why a reliable figure only comes after the concept

At the start there is usually an idea: “We need a tool for order processing.” On that basis, a provider can only give a rough order of magnitude. Anyone who promises more has either built in reserves or will renegotiate later.

A figure becomes reliable only once the workflow is described: in the high-level concept for the whole and the order of the areas, in the detailed concept for the first area. What goes into both is explained in the guide High-level and detailed concept. Whether a fixed price or billing by effort fits better afterwards is compared in Fixed price or time and materials.

Comparing quotes

Two quotes with different totals often do not describe the same work. So do not just compare the total, but also what lies behind it:

  • Does it describe which workflows and special rules are included - or is there only a keyword?
  • Are connections, data migration and testing included, or moved out as “optional”?
  • What do operation and maintenance cost after launch?
  • How are changes that come up during the project billed?
  • What belongs to you at the end, and what does a later switch cost? More in the guide Who owns your software.
  • Where do you start, and what does only this first step cost?
  • How much of your employees’ time is planned in?

A provider who answers these points calmly and specifically has understood your project. Which questions to ask about the estimate itself is covered in the guide on estimates. One who names an exact figure without a conversation about your workflows has not.