Every software company gets asked the same first question, and almost none of them answer it in public. That looks evasive. It is worth explaining why, and then explaining what you can do about it.
Why there is no price list
The same six words describe wildly different projects.
"We need a booking system" can mean a form on your website that emails the office. It can also mean live availability across three properties, deposits taken, refunds handled, rates that change by season, and everything syncing with the platform you already sell through. Same sentence. The second one is many times the work of the first.
A number published before anyone knows which of those you mean is one of two things: a headline price for a fixed package that may or may not be what you need, or a figure that will be corrected upwards once the details arrive. Neither helps you.
What you can be told in public is what moves the number, so you can work out roughly where you sit before you talk to anybody.
What you are actually buying
Weeks of skilled attention. Everything below is really a question of how many weeks something adds.
That is also why estimates should be given to you in weeks as well as money. Weeks are checkable. If someone says twelve weeks and cannot name what happens in each of them, the number underneath it is a guess.
The five things that move the price
1. Scope, counted properly
Not "features". Count the things a user can do: create a booking, change a booking, cancel one, refund one, see today's arrivals, add a note, export the month. Each of those is a screen, a rule about who may do it, and a set of ways it can go wrong.
A useful exercise before any conversation: write the list of actions in the order they happen in real life. Most people find their "small system" has forty of them, or discover that the thing they thought was the project is actually three actions and the rest is reporting.
2. Integrations
Every system yours must talk to is a small project of its own. And the price is set almost entirely by the other system, not by yours.
A modern product with a documented interface is straightforward. A ten-year-old package where the supplier wants a fee and six weeks to discuss access is not. Something with no interface at all can still be done -- scheduled exports, a direct read of the database, a script doing what a person would do -- but it is slower to build and more fragile to run. We cover the options in integrations and migrations.
Before you ask for a price, find out three things about each system you want connected: does it have a documented interface, who holds the administrator login, and does the supplier charge for access. Those three answers move estimates more than anything else on this page.
3. Moving your existing data
Everyone assumes this is the easy part. It is usually the part that overruns.
Moving data is quick. Cleaning it is not. Real business data has the same customer entered four times with different spellings, dates in three formats, a column that was repurposed in 2019 and still has the old meaning in the rows above, and a field called "notes" holding information the business genuinely depends on.
None of that is a criticism; every business has it. But somebody has to make decisions about it, and that somebody has to be you, because only your team knows which of the four duplicate customers is real. Budget your own time for this, not just theirs.
4. How many kinds of user
One kind of user -- everybody sees everything -- is the cheapest system to build. Each additional type adds its own screens, its own permissions, and its own testing.
Two or three roles is normal: an owner, a member of staff, maybe a customer. When a specification arrives with seven, it is worth asking whether some of them are really the same role with a slightly different view. Sometimes they are not, and the cost is justified. Often three of them can merge on day one and split later if needed.
5. Whose rules you have to follow
Software handling children's data, health records or card payments carries real obligations, and meeting them is work rather than paperwork: access by role, audit logs that record who looked at what, retention and deletion rules, hosting in a specific country, encryption, and an agreement covering how data is handled.
If you run a school or a clinic, assume this is a meaningful part of the project and be suspicious of anyone who does not raise it before you do.
What matters less than people expect
The word "AI". Adding a model to a workflow is often the cheapest part. The cost is in the plumbing around it: getting clean information to it, the review step, and what happens when it is wrong.
How much data you have. A database does not care whether it holds ten thousand records or ten million, within the range most businesses operate at.
Design polish, up to a point. Making a system clear is essential and included. Making it distinctive is a separate, optional piece of work with its own price.
The ongoing cost nobody mentions
Ask for this separately and in writing. It normally has three parts: hosting and third-party services; usage costs where they apply, such as per-minute charges on phone calls or per-document charges on processing; and maintenance.
Maintenance is the one that gets skipped in sales conversations. Software does not rot on its own, but the world around it moves -- browsers update, payment providers change their interfaces, phones require new versions, security patches arrive. A system nobody touches for a year usually still runs. A system nobody touches for three years usually does not.
A fair question to ask any supplier: what happens if we pay you nothing for twelve months? If the honest answer is "it keeps working, then these specific things start to break", you are talking to someone who has thought about it.
How to get a real estimate in a week
Put together one short pack. This is the difference between a two-week guessing game and a number in a few days.
- One page of what it must do, written as actions in the order they happen. Plain sentences.
- The list of systems it must talk to, with names, versions, and who holds the login.
- The user types and what each is allowed to see and do.
- A sample of your real data. A spreadsheet export, a photograph of the paper form, last month's invoices. Messy is fine. Messy is the point -- clean sample data produces optimistic estimates.
- Your budget range. People hate this one, on the theory that any number offered will be spent. The cost of withholding it is worse: you spend two weeks receiving proposals for the wrong size of project. A straight supplier uses the range to tell you what fits inside it, or to tell you that nothing does.
Then ask for the estimate as a range, with the assumptions listed and the two or three things that would push it to the top of the range. Our own version of this sits in how we work.
What a good estimate looks like
A range rather than a single number. The assumptions written out. An explicit list of what is not included -- your data cleaning, your content, your team's time, third-party fees. Phases, so you can stop after the first one. Payments tied to things being delivered rather than to dates in a calendar. And a named person on their side who will actually do the work.
When the honest answer is not to spend it
If the problem costs you less per year than the fix costs once, and there is no growth argument, do not build. Something else in your business will pay back faster.
If you cannot name the person inside your company who will own this system, stop. Every build needs somebody who answers questions, makes decisions and chases their own colleagues. Projects without that person are the ones that go quiet a long way in and never quite finish.
And if your process is about to change anyway -- a merger, a new location, a regulation coming -- wait. Software built around a process that is about to be rewritten gets rewritten too, at your cost.
Filed under
- pricing
- buying software
- estimates
- budget