“Roughly what does something like this cost?” is the first question in almost every initial conversation, and a fair one. But the honest answer at that point is almost always: it depends. Not because the vendor is dodging, but because nobody yet knows what it depends on.

This article describes how an estimate is made. You will not find concrete figures here - they belong in your quote, not in a guide.

What the vendor needs to know

An estimate is only as good as the questions that came before it. The vendor needs to know four things:

  • The workflow: what happens from trigger to result? An order comes in, is checked, approved, picked, delivered, invoiced.
  • The people involved: who works with it, where, on which device?
  • The connections: which systems are involved? The ERP, the shop, the accounts at the tax adviser, a supplier. Every connection is its own piece of work, and whether it is feasible only shows on the other system - hence “where possible” in every quote.
  • The exceptions: what happens when the customer cancels, the goods are missing, the invoice comes back? The exceptions are where the work is.

Most of this is in good process documentation. Without it, the vendor has to guess or ask. Good vendors ask.

Idea, high-level concept, detailed concept

What the estimate is based on decides how accurate it can be:

Basis What is known What the estimate can do
Idea “We need an order tool” an order of magnitude: does the project fit the budget at all?
High-level concept the areas, their sequence, the rough connections a range per area and the decision where to start
Detailed concept every step, every screen, every exception of the first area a reliable estimate for that area

This is why we estimate the first area only after the detailed concept and the further areas only roughly. A precise figure for the whole, before anyone has seen the workflow, would be a figure with nothing behind it. What goes into the high-level and detailed concept is covered in its own article.

What drives the effort

It is not the size of the business. A company with thirty staff can have a more complicated order workflow than one with three hundred. What drives the effort:

  • The number of exceptions. Every special path the software is meant to know is its own rule with its own check.
  • Connections to other systems. Every interface means agreement, testing and error handling. One system without a documented interface costs more than three with a good one.
  • Legacy data. If customers, items and open orders are to come over from the old system, they have to be cleaned and mapped.
  • Roles and permissions. “Everyone sees everything” is simple. “Field sales see only their own customers, trainees may not approve anything, accounts see prices, the warehouse does not” is work.
  • Screens and documents. Every form, every list, every printout - quote, delivery note, invoice, label - has to be designed, filled and checked.

Why small things are big and big things small

What looks big to the business is often small for the software: a thousand customers instead of a hundred change nothing in the program.

Conversely, some things that sound like trifles are a lot of work. “The invoice should look the way it does now” means rebuilding a document with every special rule that has grown into it over time. “It should work offline too” means storing data on the device, syncing it later and resolving conflicts. “The customer should see the status” means access for outsiders with their own permissions and their own security.

A good vendor tells you which of your wishes belong in which group.

A range instead of a single figure

An honest estimate is a range, not a single number. The lower end applies if everything runs as described. The upper end covers the exceptions that still turn up during the build - and they always turn up. The better the basis, the narrower the range.

A single figure is not a sign of certainty. It more likely shows that the vendor has either built in a lot of buffer or is hoping the exceptions will not come.

What you can do so the estimate holds

  • Make decisions. Open questions left standing in the detailed concept get decided during the build - expensively and in a hurry. “We will sort that out later” is the most common cause of extra effort.
  • Name a contact person. Someone in the business who knows the workflow and answers questions promptly.
  • Provide examples. Real documents, real lists, real records from the old system, anonymised where necessary.
  • Keep the first area small. Whatever is not needed in the first step goes into the second.

Warning signs in estimates

  • An estimate without questions. Anyone who names a figure after the first conversation has not seen your business.
  • “All inclusive”. Connections, legacy data and exceptions in one flat price mean there is buffer somewhere or that extra charges will follow later.
  • No assumptions in the quote. A good estimate writes down what it assumes: the number of screens, connections and roles.
  • The effort depends only on the number of users. That is a licence model, not an estimate.
  • Not a word about what is not included. Training, data migration, running the software after launch - it has to go somewhere, otherwise it arrives as a surprise.

What else marks a suitable vendor is covered in the article on choosing a software partner.

Questions for the vendor

  • What did you base the estimate on - a conversation, a high-level concept or a detailed concept?
  • Which assumptions are in the figure?
  • What is not included?
  • What happens when an exception nobody knew about turns up during the build?
  • How wide is the range, and what would make it narrower?

If you get answers to these questions, you can judge the estimate. If you get none, you have at least learned something about the vendor.