CentriWebCustom software costs whatever the agreed scope takes to build, multiplied by the developer’s rate, plus a margin for testing, project management and the unknowns. That’s why there’s no honest single figure: a simple internal tool and a customer-facing app with payments and integrations are very different jobs, priced very differently. To get a useful number, write down what the software must do, get quotes against that same written scope, and budget for running costs every year after launch.
This guide explains how quotes are built, what pushes the cost up or down, what it costs to keep software running, and how to brief developers so the quotes you get are comparable. Any figures below are worked examples to show the arithmetic, not market prices.
How a quote is built: scope, hours and rates
Almost every software quote, however it’s presented, comes from the same three steps.
1. Scope
The developer breaks your idea into features: logging in, a customer list, a quote builder, an approval step, an invoice export, notifications, reports. The more precisely each one is described, the more accurate the estimate.
2. Effort
Each feature gets an estimate in hours or days, covering design, building, testing and fixing. Good estimates also include time for setting up hosting, deployment, project meetings and documentation, which are easy to leave out and always needed.
3. Rate and contingency
The effort is multiplied by a rate, then a contingency is added for things nobody has thought of yet.
A worked example: suppose a developer estimates a client portal at 40 days of work, and charges a hypothetical $1,000 a day. That’s $40,000. Add 20% contingency and the budget is $48,000. Halve the features and you roughly halve the days. Double the rate and you double the price. The same arithmetic applies whether the quote is presented as a single fixed figure or a set of milestones.
When two quotes for “the same app” are far apart, it’s almost always because the developers assumed different scopes, different quality standards or different amounts of testing, not because one is simply cheaper. That’s why the written scope matters more than the headline number.
What makes software cost more
- Integrations. Connecting to your accounting software, CRM, payment provider or a supplier’s system takes time, and some systems are much harder to work with than others.
- Several user types. Staff, managers, customers and contractors who each see different screens and permissions multiply the work.
- Customer-facing polish. Software your customers use needs more design, more testing on different devices and clearer error handling than an internal tool.
- Mobile apps. Native apps for iPhone and Android, plus app store submission, add work compared with a web app that runs in the browser.
- Payments and sensitive data. Taking payments, storing health or financial information, or meeting a client’s security requirements adds design, testing and review.
- Moving old data. Cleaning and importing years of spreadsheets or records from an old system is often underestimated.
- Unclear or changing requirements. Every change after work starts means rework.
What makes it cost less
- A smaller first version. Build the one workflow that saves the most time or earns the most money. Add the rest once people are using it.
- Off-the-shelf parts. Use existing services for login, payments, email and file storage rather than building them.
- A web app before a mobile app. A well-built web app works on phones. Native apps can come later if they’re needed.
- Clear decisions, quickly. One person on your side who can answer questions and approve screens saves days of waiting.
- Clean data. Tidy your spreadsheets before the developer imports them.
- Checking you need custom at all. Sometimes an existing product does 90% of the job. Our guide on client portals: build or buy walks through that decision.
Running costs after launch
The build is a one-off. These costs carry on every year, and they belong in your budget from day one.
| Running cost | What it covers | What to ask |
|---|---|---|
| Hosting and database | The servers the software runs on, backups and monitoring | Whose account is it in? How does the cost change as usage grows? |
| Third-party services | Email sending, SMS, maps, payments, file storage | Which services are used, and how are they priced? |
| Maintenance | Security updates, framework upgrades, fixing things that break when other systems change | Is there a monthly support arrangement, and what’s included? |
| Small improvements | The changes your team asks for once they’re using it | How are changes estimated and approved? |
| App store fees | Developer accounts, if you have mobile apps | Whose name are the accounts in? |
Software that nobody maintains slowly stops working as browsers, phones and connected systems change. Ask every developer what they recommend for ongoing support, and how they’d hand the work to someone else if needed. Proper hosting with backups and monitoring is part of that.
Who owns the code
According to IP Australia, intellectual property created by a contractor belongs to the contractor unless the contract says otherwise. If you’re paying for custom software, make sure the contract assigns the code and other IP to your business, usually once it’s paid for, and that you have access to the code repository and every hosting account. This is general information, not legal advice; have a lawyer review the contract for any significant project.
Fixed price, time and materials, or staged
| Approach | How it works | Suits | Trade-off |
|---|---|---|---|
| Fixed price | One agreed price for an agreed scope | Small, well-defined projects | Certain budget, but changes are priced as extras, and the quote includes the developer’s risk margin |
| Time and materials | You pay for hours worked at an agreed rate | Projects where the detail will be worked out as you go | Flexible, but you carry the risk of overruns, so you need regular reporting and a cap |
| Staged | A paid discovery or design stage, then fixed or capped prices for each build stage | Most small business projects | More steps to manage, but you can stop or change direction after each stage |
For a first project with a new developer, a staged approach is usually the safest. A short discovery stage produces a written scope and screen designs that you own, and you can take that scope to another developer if you choose.
How to brief developers so quotes are comparable
A good brief doesn’t need technical language. It needs to describe the work clearly enough that every developer is pricing the same thing.
- The problem. What’s slow, costly or error-prone today, and what it costs you.
- The users. Who will use the software, roughly how many, and on what devices.
- The workflows. Step by step, what each user needs to do. Screenshots of current spreadsheets or forms help.
- Connections. Which systems it needs to talk to, and what data moves between them.
- Must-haves and nice-to-haves. Separate them clearly, so developers can price a first version.
- Constraints. Deadlines, budget range, and any security or privacy requirements.
- What you want back. Ask every developer to break the quote down by feature, list what’s excluded, state assumptions, and include ongoing costs and IP ownership terms.
If one quote is much lower than the rest, compare the assumptions line by line. The gap usually shows up as something left out.
The same approach works for websites. Our guide on what a small business website costs covers how those quotes are built.
Where to start
- Write down the one workflow that would save the most time or money if it were automated.
- Check whether an existing product already does most of it.
- Write a short brief using the checklist above, splitting must-haves from nice-to-haves.
- Ask two or three developers for a quote broken down by feature, with running costs and IP terms.
- Consider a paid discovery stage before committing to the full build.
- Budget for hosting and support every year, not just the build.
If you’d like a second opinion on a brief or a quote, our custom software and portals page explains how we scope and price projects, or you can book a call and talk it through.