It's the first question almost everyone asks, and it's a fair one. The honest answer is that custom software costs whatever the specific thing you need takes to build, and that varies so much from one business to the next that a ballpark would mislead you more than it helped. So instead of a number, this article explains what makes the effort go up or down, why any range quoted before someone has understood your business is a guess, and how to get a real, fixed figure before you've committed to anything.
Why a ballpark misleads
Two projects can both be called a booking system and have almost nothing in common. One is a single calendar that takes a name and a time. The other is what we built for The Armstrong Clinic: four services with four different patient journeys, two diaries with a two-hour travel rule between them enforced by the database, slots held for thirty minutes until payment clears, clinical approval before certain treatments can be booked, and a separate portal for partner practices.
Same label, very different amounts of work. A range wide enough to cover both tells you nothing, and a range narrow enough to be useful is wrong for one of them. That's why we don't quote before we understand what's being built.
"A price given before the problem is understood is a guess with a pound sign in front of it."
What changes the effort: the people and journeys
The biggest driver is how many different kinds of people use the system and how differently each of them moves through it. Every type of user brings its own screens, its own permissions and its own rules. The Armstrong Clinic has patients, a clinician running the admin and partner practices with their own portal. Loxwood Sports has members booking courts and paying online, and every director with their own admin login.
A tool used by one team for one job is a much smaller piece of work than a platform used by the public, your staff and your partners.
What changes the effort: the systems it has to talk to
Integrations are often where the real work is. Connecting to another system means understanding its data, handling the moments it's slow or unavailable, and keeping both sides in agreement. The Armstrong Clinic platform writes patient data straight into OxygenRX, a regulated prescribing platform, and takes payments through Stripe. For Ballongifts we built an API bridge that keeps orders, stock movement and tracking in sync with the fulfilment partner in real time.
Each connection adds effort. It's usually still cheaper than rebuilding what the other system already does well.
What changes the effort: the rules that have to hold
Some rules are nice to have. Others must never be broken: two patients can't win the same slot, a booking can't exist until it's paid for, a figure on a report must match the invoice it came from. Rules like that have to be enforced where they can't be bypassed and tested so they stay that way. The Armstrong Clinic platform has 182 automated tests guarding its booking, eligibility and payment rules.
The more there is riding on the rules, the more of the work goes into making sure they hold.
What changes the effort: how much it replaces, and what it produces
Loxwood Sports replaced three systems with one platform, which meant one build had to cover membership, payments, bookings, communications and eighteen board reports. Classic Towing needed branded invoices and formal insurance reports laid out exactly as the business wanted them seen. Reports, generated documents and exports all take time to get right, because they're what other people read.
Then there's what happens after launch: hosting, security, backups, monitoring and further development. For Loxwood we run all of that, because a volunteer board shouldn't have to.
How to get a real number before you commit
This is what our method is for. Discovery comes first and costs nothing: we sit down with you before anything is agreed and before you've spent a penny, and learn how the business actually runs, what's getting in the way and what finished looks like.
Then we write a plan you can read: the feature set, the security model, how people will use it and what it connects to. We present it, refine it with you until nothing is left open to interpretation, and you get a defined scope and a fixed quote before any development starts. You know what's being built, to what standard, in what order and for how much, before you commit.
During the build you see the work at staged reviews rather than at the end, so any correction is made while it's still small and cheap.
Ways to keep the cost in proportion
Start with the job that costs you the most time today. Connect the tools that already work rather than replacing them. Be clear about which rules are essential and which are preferences. And be wary of any quote that arrives before anyone has asked how your business works: either it has padding built in to cover what they don't know, or it will grow once they find out.
If you're still deciding whether building is right at all, our article on the signs you've outgrown off-the-shelf software is a good place to start.
The quickest way to find out what your project would cost is to tell us about it. The first conversation is free, and you'll get a straight answer about whether we're the right fit. See what we build on our custom software development page.
Start the conversation →
