The honest answer is that nobody can tell you, and this page is not going to pretend otherwise. What it will do is show you what the number is actually made of, so that when you do get quotes you can tell which one understood the job.
That is not evasion. Custom software is priced the way an extension is priced. A builder who quotes before seeing the site is quoting for the version in their head, and the difference between that version and yours turns up later as a variation. The same thing happens in software, except the foundations are invisible, so the variations arrive further in and cost more to fix.
If you want a number for your specific situation, the fastest route is a short conversation about the process you want to fix. Everything below is what that conversation is for.
Why a number without a scope is meaningless
Two businesses ask for “a quoting system”. One wants a form that emails a finished PDF. The other wants something that reads a measured take-off, applies regional pricing, keeps a version history and syncs to their accounts package. Both describe it in one sentence and both use the same words.
The gap between those two is not a percentage. It is a different piece of software. Any supplier who quotes both from the sentence alone is either guessing high enough to be safe, which you overpay for, or guessing low to win the work, which you pay for later.
The six things that actually move the price
1. How many decisions the software has to make
Storing and displaying information is cheap. Deciding something is not. Every rule (“if the job is over this size, route it to a senior estimator”) is a branch that has to be specified, built and tested. Ten rules is not ten times one rule, because the rules interact.
2. How many other systems it has to talk to
This is the one most people underestimate. A standalone tool is a known quantity. The same tool that has to read from your accounts package, write to your calendar and stay in step with a supplier feed is three integrations, and integrations fail in ways you do not control. Each one needs error handling for the day the other end changes something without telling you.
3. What state your existing data is in
If the information the system needs currently lives in one clean spreadsheet, that is a morning. If it lives across a shared inbox, three spreadsheets with different column names and one person’s memory, the software is the easy part. Data migration is routinely the single largest line on a build, and it is almost never in the customer’s original estimate.
4. How many different kinds of user
One person using a tool needs one screen and no permissions. An office team, a field team on phones and a director wanting a weekly view is three interfaces, a permission model and a decision about what each of them is allowed to see and change. That is not three times the work, but it is not one times it either.
5. What it costs when the software is wrong
A tool that suggests a task order can be wrong occasionally without much consequence. A tool that issues priced quotes to customers cannot. The second one needs validation, an audit trail and a way for a human to catch it before it goes out. Correctness is a cost, and it is the right one to pay when money or safety depends on the output.
6. Who owns and maintains it afterwards
Software is not a purchase, it is an asset with running costs. Hosting, updates when the platforms underneath it change, and someone to call. A quote that covers only the build is not wrong, but it is incomplete, and you should ask what year two looks like before you compare it with anything.
Why day rates tell you less than you think
A day rate is a real number, which makes it feel like solid ground. It tells you what an hour of someone’s attention costs. It does not tell you how many hours the job takes, and that is the entire question.
Two suppliers with the same day rate can differ several times over on the same brief, because one has built the thing before. Experience shows up as fewer days, not as a lower rate. When you compare quotes, compare the total for a defined outcome, and make sure both are describing the same outcome.
What a supplier needs before a real quote is possible
You do not need a specification. You need to be able to answer these:
- What is the process today, step by step, including the awkward parts people work around.
- How often does it happen, and how long does it take now.
- Where does the information come from, and where does it need to end up.
- What has to be true for the result to be correct.
- Who will use it, and on what.
- What happens today when it goes wrong.
If a supplier does not ask most of these, the number they give you is not about your business.
Questions worth asking anyone quoting you
- What is not included in this figure.
- What happens to the price if the integration turns out to work differently than expected.
- Who owns the code and the data at the end.
- What does it cost to run for a year after launch.
- What is the smallest version of this that would be useful, and what would that cost on its own.
That last one matters most. A supplier who can describe a smaller first version has understood the problem well enough to find its core. One who insists the whole thing must be built at once may simply not know which parts are load bearing.
When you should not build custom
Being straight about this is part of the job. Do not commission custom software when:
- An off-the-shelf tool already does it and your objection is the subscription cost. Building is almost always the more expensive way to avoid a fee.
- The process changes every few months. You would be paying to set concrete around something still moving.
- Nobody internally owns the process. Custom software makes a defined process faster; it does not create the definition.
- You cannot say what “working” would look like. If success is not measurable, neither is completion.
How we quote
We do not put a price on this page because a price without your process behind it would be a made-up number, and you would be right to distrust it. What we do instead is spend an hour on the process itself: what it costs you now, what a better version looks like, and what the smallest useful first build would be.
You leave that call knowing what the problem is and what can and cannot be solved with software, whether or not you go on to work with us. If it turns out you should buy something off the shelf, we will say so.