Nobody can quote custom software from a page. What we can do is show you exactly which decisions move the number, so you can estimate your own project and read a quote critically.
Every honest answer to this question starts the same way: it depends on scope, and anyone quoting before understanding your scope is guessing, discounting to win the work, or planning to make it up in change requests later.
That is not a satisfying answer, so here is a more useful one. Software cost is driven by a small number of specific decisions, and once you know what they are, you can estimate the shape of your own project — and tell the difference between a quote that is competitive and one that is simply wrong.
This is the single largest driver, and the one clients consistently underestimate. Each role — cashier, manager, accountant, owner, customer — needs its own screens, its own permissions, and its own testing. A system with one role is a fraction of the work of the same system with five, even if the underlying data is identical.
When you brief a project, list every person who will log in and what each one should not be allowed to see. If that list has six entries, expect the estimate to reflect six.
Integrations are where estimates go wrong, because each one is a negotiation with somebody else's system. A payment gateway, an SMS provider, an accounting package, a courier API, a biometric device, an existing POS — each carries its own authentication, error handling, sandbox testing and edge cases.
Worse, some integrations turn out to be impossible: the system you want to connect to has no API, or its API does not expose what you need. That is why we check integration feasibility during discovery rather than assuming it, and why an integration-heavy project should never be quoted from a brief alone.
Migrating data is rarely a technical problem and almost always a data-quality problem. Two spreadsheets with the same customer spelled three ways, opening balances that do not reconcile, items with no consistent code. Cleaning that is real work, and it usually needs your team as much as ours.
A project starting from empty is materially cheaper than the same project inheriting five years of history. If you have history, expect a migration line item and a data clean-up task list for your side.
A list on a screen is cheap. A report that aggregates across time periods, compares against targets, drills down to source transactions and exports in a specific layout is not. Reporting requirements often account for a surprising share of a system's cost because each report is a small piece of custom logic.
The practical advice: name the five reports you would actually open weekly. Those are worth building properly. The other twenty on the wish list can wait until the system is live and you discover you never needed them.
A web application used on desktops is the baseline. Add a mobile app and you have added a second product with its own build, testing and app-store process. Add offline capability and you have added synchronisation logic, which is genuinely difficult work. Add hardware — printers, scanners, scales, biometric devices — and you have added device-specific testing.
None of these are unreasonable requirements. They are just decisions that each carry a cost, and they should be made deliberately rather than assumed into the brief.
A build price with no support arrangement is an incomplete price. Software needs dependency and security updates, hosting attention, backup verification, and someone to call when something breaks at month-end. If a quote omits that, the cost has not disappeared — it has just been deferred to a moment when you have no leverage.
We quote the build and the optional monthly support separately, so both numbers are visible before you commit.
Discovery first, producing a written functional scope. From that scope comes a fixed price and a delivery date, both agreed before development starts. Changes during the build are reordered within the same budget where possible, and quoted separately where they add genuine scope.
We prefer fixed price to hourly billing for defined projects, because it puts the estimating risk on us rather than on you. For ongoing team-extension work a monthly rate is more honest, and we say which model fits your project rather than defaulting to whichever suits us.
Assume the cheapest quote has excluded something, and find out what. Ask each supplier the same five questions: what exactly is in scope in writing, which integrations have been feasibility-checked, is data migration included, what happens to the source code and whose name the hosting is in, and what support costs after launch.
A quote that is 40% below the others is not usually a bargain. It is usually a smaller scope, an hourly arrangement that will exceed the estimate, or a supplier who has not thought about the integrations yet.
Straight answers, including the ones that rule us out.
The pages people read next, and the products that connect to this one.
POS pricing is quoted in so many different shapes — per till, per month, per branch, one-off — that comparing suppliers is genuinely hard. Here is what actually drives the number.
Read moreWebsite quotes vary more than any other kind of software quote, mostly because “website” describes five different products. Here is what separates them.
Read moreCustom software is not automatically better, and a product is not automatically cheaper. Here is the framework that actually settles the decision.
Read moreMost software projects fail on communication and scope, not on code. Here is how to evaluate a development company for the things that actually go wrong.
Read moreA short scoping conversation is enough for a fixed quote. No obligation, and we will tell you if a cheaper route exists.