Search for what custom software costs and you will find ranges wide enough to be useless. That is partly evasion and partly honest: the same brief genuinely can cost very different amounts depending on four or five specific things. This is an attempt to name them, so you can estimate your own position before anyone quotes you.
Why nobody publishes a number
Two reasons, and it is worth telling them apart. The legitimate one is that scope varies enormously and a published price would be wrong for most enquiries. The less legitimate one is that opaque pricing lets a vendor charge based on how much they think you can pay.
You can tell the difference by asking what would make the number go up. A studio with a real process answers immediately and specifically. A studio pricing off your perceived budget gets vague.
The four things that actually move the price
1. How many modules
A module is a thing with its own records that people create, edit and close: projects, invoices, patients, matters. It is not a chart. Charts are cheap because they read data that already exists; modules are expensive because each one needs its own screens, validation, permissions and edge cases.
This is the single biggest driver. Going from four modules to six is not a fifty percent increase in work, because the connections between them grow faster than the count does.
2. Integrations, and which ones
The number matters less than the target. An integration with a well-documented API like Stripe or Slack is predictable work. An integration with a legacy system that has no API, or a vendor that gates access behind a partner programme, can cost more than the rest of the build combined.
If a quote treats all integrations as equivalent, the studio has not checked. Ask specifically whether they have confirmed your systems expose what is needed, because the honest answer sometimes is "we cannot until we look."
3. Roles and permissions
The most underestimated line by a distance. "Different people see different things" sounds like a setting. In practice it touches every screen, every query and every test in the system, and it needs its own admin interface for managing who is what.
If you can launch with everyone seeing everything, you will save a meaningful amount. Many small teams genuinely can, and add roles later when the team is bigger.
4. Data migration
Getting ten years of history out of the old system is often harder than building the new one. Messy data, inconsistent formats, duplicates that have to be resolved by someone who knows the business. Ask whether migration is in the quote, because it frequently is not.
Three pricing models, and what each optimises for
- Hourly. Transparent and honest about uncertainty, but it puts every overrun on you and gives the studio no incentive to be quick. Works when scope genuinely cannot be pinned down.
- Fixed price. Puts the risk on the studio, which is why it only works against a tightly written scope. Be suspicious of a fixed price offered before anyone has asked what your data looks like.
- Quoted per project. A price agreed upfront for a scope agreed upfront. The middle path, and it depends entirely on the scoping conversation being real.
None is inherently better. What matters is whether the model matches how well the work is understood.
How to compare quotes that look nothing alike
Normalise them before comparing. For each quote, write down: the number of modules, whether integrations are named specifically or described vaguely, whether roles are included, whether migration is included, how many revision rounds, whether hosting and deployment are included, and who owns the source code at the end.
That last one decides whether you are buying an asset or renting a dependency. A cheaper quote where the studio retains the code is not cheaper.
Red flags
- A number before any questions. Nobody can price work they have not understood.
- "Unlimited revisions." Either it is not true, or it is priced in, or the project never ends.
- No mention of what happens after handover. Hosting, ownership and support should all be explicit.
- Vagueness about your existing systems. The feasibility of your integrations is knowable, and should be checked before you commit.
What to bring to a scoping call
The accuracy of any quote depends almost entirely on what you bring. Useful: the list of modules you think you need, the systems it must talk to and who administers them, roughly how many people will use it and whether they need different access, a sample of your real data including the messy parts, and the one question you most want the tool to answer.
With those, a quote is a considered number. Without them, it is a guess with a margin attached, and the margin is there to protect the studio from what it was not told.
If you are still deciding whether to build at all, the build-versus-buy comparison is the better place to start. If you know you are building, scoping a first version is what makes the number smaller.