"How much does custom software cost?" is one of the most common questions we hear, and the honest answer is that it depends on a short list of things you can learn to judge yourself. We quote each project individually and we do not publish prices, so this guide does something more useful: it explains what pushes the cost up or down, so you can scope a project sensibly and compare quotes fairly.
Why one price does not exist
Two projects described the same way, "a system to track our jobs," can differ by an order of magnitude. One is a single screen and a table. The other connects to accounting, handles three kinds of user, prints labels and has to be right to the cent. The label is the same and the work is not. Anyone who names a price from a one-line description is guessing, or is selling you something else.
The main cost drivers
1. How many different things the software must do
Count the distinct jobs: enter an order, schedule it, invoice it, report on it. Each job has its own screens, rules and edge cases. Doubling the number of jobs more than doubles the work, because they have to fit together.
2. How many kinds of people use it
An owner who sees everything is one case. Add office users who see part of it, customers who log in to see their own orders, and a supplier who uploads files, and you have four sets of permissions, four sets of screens and a lot more to get right. Anything that outsiders can log into also needs more care about security.
3. How exact the rules are
"Calculate the price" can mean multiplying two numbers or applying customer-specific discounts, quantity breaks, tax rules and rounding. Rules that are written down and consistent are cheap. Rules that live in one person's head, with exceptions for favorite customers, cost time to uncover and to get right.
4. Connections to other systems
Each system the software has to talk to is its own piece of work: accounting, a payment service, your e-commerce store, a shipping carrier, a machine on the floor. The cost depends on how good that system's interface is. A well-documented one is quick. An old package that only exports files is slow, and the matching rules between the two systems take thought.
5. Existing data that must come across
Moving ten years of records from spreadsheets into a new system is a project inside the project. Messy, duplicated or inconsistent data has to be cleaned, and someone who knows the business has to decide what is right. The more history you need, the higher the cost.
6. What happens when it goes wrong
Software that shows a report can be wrong occasionally without much harm. Software that moves money, controls stock or files something with a regulator needs more checking, logging and care. The cost of being wrong sets how much checking is worth buying.
7. Security, privacy and access
Sign-in, roles, an audit trail of who changed what, encryption and careful handling of personal data all add work. They are not optional for much business software, and it is cheaper to plan them from the start than to add them later.
8. Where it runs and who looks after it
Software has to live somewhere, be backed up, be patched and be watched. Running it on a service we host, on a cloud account you own, or on your own hardware changes the setup and the ongoing work. Ask about the running cost as well as the build.
9. How polished the screens need to be
An internal tool for three people can be plain and fast. A portal for your customers, with your brand, on every screen size and meeting accessibility needs, takes more design and checking.
10. How fixed the target is
The most expensive thing in software is changing your mind after it is built. A clear description that stays put is cheap. A project where the goal moves each week costs more, and the cost shows up as delay.
What brings the cost down
- A smaller first version. Build the one job that hurts most, use it, and add the rest after you have seen it work.
- Fewer exceptions. If twelve customers get special rules, ask whether eight of them really need them.
- Samples and examples. Real documents, real spreadsheets and real invoices save hours of guessing.
- A decision maker who answers quickly. Waiting on questions is a hidden cost on every project.
- Using what already exists. If an off-the-shelf tool already does most of a job well, build only the rest or connect to it.
- Clean data. Tidy your spreadsheets before the move, not during it.
What pushes it up
- Wanting everything in the first release.
- Systems with poor or no interfaces.
- Rules nobody has written down.
- Several groups of users with different needs.
- A tight date on a large scope.
- Changing the requirements during the build.
How to scope the first version
Write your answers to these in plain sentences.
- Who is the first user, and what is the one job they do? One person, one job.
- What do they use today? A sheet, a paper form, an old tool. Bring a copy.
- What does a good result look like? For example: "an order entered once appears on the shop schedule and the invoice."
- What must not happen? Double bookings, a wrong total, data seen by the wrong person.
- What can wait? List the nice-to-haves and park them for version two.
- What does it connect to? Name each system and what has to pass between them.
What to prepare before asking for a quote
- the one-page description above;
- samples of the documents and spreadsheets in use now;
- a list of the systems it must connect to, with versions if you know them;
- a rough count of users and their roles;
- how much history you need to bring across;
- a date, if one is real, and the reason for it;
- who decides, and who answers questions.
With that in hand, a quote becomes a comparison of like with like. Be wary of any estimate that arrives without questions.
How to compare quotes
Ask each supplier what is included and what is not: hosting, backups, training, changes after handover, who owns the code. Ask what they assumed. A lower number that leaves out half of this list is not lower.
Next step: a scoping assessment
For a project large enough that a wrong guess is expensive, we offer a paid scoping assessment. You get written findings on what you need and what can wait, and a plan with a set price for the first build. You can take that plan to any supplier.
We build internal tools, customer portals and complete business systems, including ERP, CRM, support ticketing and billing. Read about it on the custom applications page, or describe the project through the contact form.