The short answer
Nobody can honestly price custom software before they understand the work. The cost is driven by things you can identify in advance: business rules and exceptions, user roles and approvals, integrations, data migration, and security, privacy and audit obligations. Add hosting, support and maintenance for every year the software is in use; that is part of the cost, not an afterthought.
The practical approach is to budget in three pieces: a small, fixed-scope discovery; a first release sized to the most valuable part of the problem; and a yearly allowance for running and improving what you built. If a quote arrives without any of those, ask why.
What actually drives the cost
Screens are not what make software expensive. Rules, connections and data are.
| Cost driver | Why it matters | What to have ready |
|---|---|---|
| Business rules and exceptions | Every "except when" needs design, code and testing. Exceptions are where most effort goes. | Real examples of awkward cases, not just the normal path |
| User roles and approvals | Each role needs its own permissions, screens and tests, including what it must not see | A list of who does what, and who signs off |
| Integrations | Connecting to your ERP, CRM, accounting or Microsoft 365 depends on their APIs, limits and data quality | Names and editions of the systems involved, and who administers them |
| Data migration | Old spreadsheets and databases carry duplicates, gaps and unwritten rules | Sample exports and an owner who can decide what is correct |
| Security, privacy and audit | Personal information brings obligations under sector laws (such as HIPAA or GLBA) and state privacy laws; some processes need full audit trails | Your privacy commitments, retention rules and any customer or regulator requirements |
| Accessibility | Public-facing software may need to meet accessibility standards, and some customers and public-sector buyers require it in the contract | Who the users are, and whether any are members of the public |
| Hosting and availability | A tool used during office hours costs less to run than one that must be available around the clock | How much downtime the business can tolerate |
Two deserve a note for US organizations. If the software handles personal information, there is no single federal privacy law: obligations come from sector laws, state comprehensive privacy laws (such as California's CCPA as amended by the CPRA, and the Texas Data Privacy and Security Act) and the FTC's authority over unfair or deceptive practices. They shape design decisions such as notices, consent, access, deletion and retention, and the FTC's privacy and security guidance is a sensible starting point. And if you are a state or local government body, or sell to one, the Department of Justice's 2024 rule applies WCAG 2.1 Level AA to government web content; courts also apply ADA Title III to many private-sector websites, and ADA.gov's web guidance explains the position. We target WCAG 2.2 AA. Designing for both from the start costs far less than retrofitting.
Why quotes for the same project differ so much
When three firms quote the same brief and the numbers are far apart, it is usually because they are quoting different things:
- Different assumptions about exceptions. One firm priced the happy path; another priced the edge cases you mentioned in passing.
- Testing and documentation included or not. Automated tests, deployment pipelines and handover documentation take real time. Leaving them out makes a quote look cheaper and the software more expensive to own.
- Data migration treated as "your job". Moving and reconciling data is often left vague. Ask who does it and how results are checked.
- Different views of risk. A fixed price includes a buffer for uncertainty. A time-and-materials estimate shows you the uncertainty instead.
- Who owns the result. Confirm that source code, infrastructure and accounts end up in your organization's name. Under US copyright law, the author is generally the first owner, and work created by an independent contractor is not automatically a "work made for hire", so an assignment of copyright must be in a signed writing. Code written by an outside firm needs a written assignment or license in the contract. Your attorney can confirm the wording.
The fair way to compare quotes is to ask each firm to list its assumptions and exclusions. The cheapest total with the longest exclusion list is rarely the cheapest project.
How to build a realistic budget
1. Fund discovery separately. A short, fixed-scope discovery maps the process, the rules, the data and the systems involved, and ends with a written scope, a release plan and an estimate in US dollars. It is the cheapest point at which to find out the project is bigger, smaller or different than you thought.
2. Size the first release to the most valuable problem. Not the whole wish list. A first release that replaces one painful spreadsheet or approval process properly is worth more than a broad release that does everything half-way.
3. Hold a contingency. Requirements change once people see working software. That is healthy, and it is why part of the budget should be held back.
4. Budget for the years after launch. Plan a yearly amount for hosting, security updates, monitoring, support and small improvements. Unfunded software becomes a risk, however good the first version was.
5. Check whether any work may qualify for incentives. The federal research credit and some state incentives can apply to qualifying software development carried out in the US, and the rules on how development costs are deducted or amortized have changed in recent years. Most routine business software will not qualify, and eligibility is decided under IRS rules, so speak to your accountant before counting on it. This is general information, not tax advice.
A hypothetical budget structure for a mid-sized distributor replacing a spreadsheet-based returns process:
- Discovery (fixed scope): map the returns process, list the exceptions, review ERP integration options, produce a scope and phased estimate.
- Release 1: returns requests, approvals and credit memos pushed to the ERP, for two user roles.
- Release 2 (only if release 1 proves its value): customer self-service portal and reporting.
- Contingency: a portion of each release held for changes that emerge in testing.
- Yearly running allowance: hosting, monitoring, updates and a small block of improvement hours.
Each line would carry its own estimate in US dollars and its own list of assumptions.
Rather talk it through? We can turn your process into a written scope and a phased USD estimate before you commit a full budget. Talk to a Promatics specialist
The questions people ask before they call us
"We are too small for custom software." Sometimes true, and we will say so. If a packaged product fits with configuration, buy it. Custom work earns its place when the process is specific to you and workarounds cost you time every week. Our build, buy or integrate guide helps you decide honestly.
"Can AI tools build this for less?" AI coding assistants genuinely speed up parts of development, and we use them, with people reviewing the output. They do not uncover your exceptions, decide what happens when rules conflict, test against your real data, or answer for the result when something breaks. That judgment and accountability are most of what you are paying for.
"What if the project runs over?" Phased releases limit the damage. Each release is scoped, estimated and accepted on its own, so you can pause, change direction or stop without being left with nothing usable.
What working with Promatics looks like
We start with discovery and a written recommendation, which may be to buy or integrate rather than build. If building is right, we agree the first release, deliver it in short iterations with regular demonstrations, migrate and reconcile your data, and hand over the source code, documentation and infrastructure in your organization's accounts. Support after launch is covered by a separate agreement so you know exactly what you are paying for each year. See custom software development for the full approach.
When to bring in help
- You can describe the process, but not yet the exceptions or the data it depends on.
- The software will hold personal information or support decisions that must be auditable.
- It must connect to at least one system you do not control.
- Nobody inside the organization will be funded to maintain it after launch.
- You have quotes you cannot compare because they assume different things.
If none of these apply and the tool is small and internal, a capable in-house developer or a low-code platform may be enough. If two or more apply, an experienced partner usually pays for itself by getting the scope and ownership right before money is spent.
Sources and further reading
Product capabilities and guidance change. These are the primary sources this article relies on, checked on the review date above.
- Internal Revenue Service (federal tax guidance, including the research credit), Internal Revenue Service
- Privacy and security guidance for business, Federal Trade Commission
- Guidance on web accessibility and the ADA, U.S. Department of Justice, ADA.gov
This article is general information, not legal, accounting or security advice for your specific situation. Examples are hypothetical unless stated otherwise.