Ask three suppliers to quote for "a bespoke booking system" and the numbers that come back can differ several times over. The instinct is to assume one of them is chancing it. Usually nobody is. The brief left more room than anyone noticed in the room, and each supplier filled that room with a different set of assumptions: about which of the dozen ways a booking can go wrong are actually worth handling, about whether the person writing the code has done this kind of system before or is learning it on your invoice, and about what happens the week after launch when something breaks and somebody has to pick up the phone.
Line the quotes up properly and the gap usually resolves into three questions, not one: what scope did each supplier think they were pricing, who is actually going to do the work, and what's included once the system is live rather than just working in a demo. Ask those three questions before comparing figures and the spread generally makes sense. Skip them and you're not choosing between prices. You're choosing between systems you haven't actually compared.
The workflow is the cost, not the feature list
The happy path is nearly always cheap. "Customer picks a slot, pays, gets a confirmation" is an afternoon's work to describe and not much longer to build. It is also almost never what makes an estimate expensive, because it is almost never what a real business runs into. The cost lives in the paths that fork off it: the payment that fails halfway through, the customer who needs to move a booking on the day, the two systems that briefly disagree about whether a slot is still available, the discount code that interacts badly with the loyalty scheme nobody remembered to mention.
A supplier pricing off a feature list will price the happy path and wave at the rest. A supplier pricing off the actual workflows will ask what happens in each of those forks, and the honest answer is usually "we're not sure yet. Let's find out." That uncertainty is not padding. It is the system. Count the workflows and their exceptions properly and you get a number that means something; count screens and you get a number that means the demo will work.
Integrations, data and the parts nobody demos
Every integration has a quality, and the quality is most of the cost. A partner system with a documented, versioned API that pushes events when something changes is a different job from one that exposes an undocumented endpoint someone has to reverse-engineer, or one that offers no API at all and has to be polled, screen-scraped or emailed a spreadsheet. The word "integration" covers all of these identically on a proposal and none of them identically in the build.
Data migration gets the same treatment: mentioned in a line, absorbed in reality. Moving records out of a legacy system nearly always means cleaning them, deduplicating them, and mapping fields that don't quite correspond to anything in the new schema, discovered one awkward case at a time. And compliance and security requirements, such as an audit trail that has to hold up to scrutiny, role-based access that matches how the organisation actually delegates authority, data residency rules, and a procurement questionnaire that lands three weeks before go-live, are either priced from the start or they're not priced at all, which means they're being priced later, under pressure, by whoever is still in the room.
Who carries it after go-live
A system that ships doesn't stop needing anyone. It needs patching, monitoring, and extending as the business it serves keeps changing around it, and that work doesn't disappear just because a quote didn't mention it. It moves to whoever is left holding it: the supplier, under a support arrangement that's either specified or improvised; an internal team that inherits code it didn't write; or nobody, which is the most common outcome and the one that shows up eighteen months later as a system too fragile to touch.
Ask who answers when something breaks at a bad time, before you need the answer rather than after. A supplier who can describe that arrangement precisely, at the quoting stage, is telling you something about how they think past the launch date. One who can't is telling you something too.
Where a cheap quote hides its costs
The cheapest number rarely represents cheaper work. More often it represents the same work with parts of it deferred rather than removed: automated tests left out, so every future change is a small gamble instead of a checked one; documentation skipped, so the next developer starts by reading the code line by line instead of a page explaining why it's shaped the way it is; a handover that consists of a folder of files and a good-luck email; an offshore team assembled for the project and reassigned the moment it ships, taking whatever they'd learned with them.
None of that is fraud. It's cost deferral, and deferred cost still gets paid, usually by whoever owns the system three years later, at a worse rate than it would have cost the first time. The build that looked cheapest at signature is very often the most expensive system to own over five years, once someone has to change it, extend it, or simply understand it well enough to trust it.
What a good estimate should show you
A supplier who has actually thought about your system will hand you something with texture: the assumptions the number rests on, stated rather than buried; phases that let you see and stop the spend as it goes rather than committing to the whole figure up front; and an explicit list of what's excluded, because a number with nothing excluded from it is a number nobody has interrogated yet. That shape tells you more about the supplier than the total does.
Before signing anything, it's worth putting the same questions to every supplier on the shortlist and comparing the answers rather than just the totals.
- Which workflows and exception paths does this estimate actually cover, and which have been assumed away?
- Is data migration and cleansing costed here, or will it be quoted separately once the legacy data turns out to be messier than expected?
- Who owns compliance and security sign-off, and is that work named in the price or assumed to happen somehow?
- What does support look like in month two, and is it with this team or handed to someone else?
- Are tests, documentation and a proper handover part of the deliverable, or an add-on if we ask?
- What is explicitly excluded from this figure?
None of this is answerable from a one-page brief, which is exactly why we run discovery before quoting anything: it's the only way to turn "a bespoke booking system" into a costed plan built on workflows we've actually mapped, rather than ones we've guessed at.
