"Roughly how much for a system?" is the question every developer gets at every networking event, and the honest answer, "it depends", satisfies absolutely nobody. Fair enough. So here's the useful version: what it depends on, and how to keep it under control.
Because bespoke software doesn't have a price list, but it does have price drivers, and once you can see them, an estimate stops being a mystery and starts being a document you can interrogate.
Two businesses can ask for "a booking system" and need projects that differ by a factor of five. The cost isn't in the label. It's in the shape of your operation, which is why serious pricing starts with discovery rather than a guess over coffee.
Workflows. How many distinct processes, and how tangled are the rules? Ten simple steps cost less than three gnarly ones full of exceptions.
Roles and permissions. Two user types who see everything is cheap. Customers, staff, managers and auditors, each seeing different slices, is real design work.
Integrations. Every external system your software talks to (payments, accounts, couriers) adds a connection that must be built, secured and kept honest when it fails.
Data migration. Moving years of history out of spreadsheets and old systems is its own project, and pretending otherwise is how launch dates die.
Customer-facing polish. An internal tool for trained staff can be plain. A public-facing product for impatient strangers cannot.
Operational importance. The more your business depends on it, the more testing, security and resilience it deserves. That's not gold-plating. That's matching the build to the consequences of it failing.
It shows its workings. It names the workflows, the roles, the integrations and the assumptions. It separates the first release from later phases, and it tells you what's excluded, which is often the most honest line in the document. A single confident number with no anatomy attached isn't an estimate. It's a hope with a currency symbol.
Phase it. Build the smallest release that improves the operation, prove it, then extend with evidence. Keep the exotic features on the roadmap until real use argues for them. And budget beyond the build: hosting, support and steady improvement are what keep the system valuable in year three, when it's quietly running your business.
One more thing, because it's true: sometimes bespoke is the wrong choice, and a good developer will say so before taking your money. If a standard product fits your model, buy it. If your process is genuinely yours, and the workarounds are multiplying, that's when bespoke software, from portals like the one we built for Darkin Architects to automation behind the scenes, starts paying for itself.
Bring us the operational headache and we'll give you the anatomy of the answer, in numbers you can challenge.