What Shapes the Cost of Custom Business Software?
On this page
A useful software estimate explains what the team will deliver, which assumptions it depends on, and what could change it. A price without that context is difficult to compare with another proposal.
At Horizon Dynamics, full project budgets start at USD 50,000. We work with an hourly team or a fixed price for an agreed module. Our Pricing & Process page explains these models and the delivery stages. This guide explains the work behind an estimate.
Choose the budget example closest to your decision
- Customer handoffs and CRM: the CRM cost guide compares internal customer operations with the same scope plus a portal. It separates migration assumptions, access checks and running costs.
- Orders, stock and operational ERP: the ERP cost guide compares module configurations while keeping the accounting system boundary explicit. It includes reservation and failed-exchange acceptance scenarios.
- A connection between systems you already use: start with source ownership, exchange rules and failure recovery. You may need a scoped integration rather than a full replacement; the module examples alone cannot price a particular connector.
Start with a working business process
“Build a CRM” leaves important questions unanswered. A more useful starting scope might be: a sales team records customer enquiries, assigns ownership, follows opportunities, and hands an accepted order to operations.
That process reveals the user roles, data, handoffs, exceptions, and reporting that must work together. It also helps identify what can wait until a later release.
For each workflow, describe its trigger, who acts, which records change, and how success is checked. Include an exception: a duplicate customer, a cancelled order, a failed integration, or a request that needs approval.
Six areas that shape the work
Workflows and permissions
A simple directory and a customer platform with team-specific access, approval rules, and multiple operating units have different scopes. List the roles, decisions, and exceptions instead of using screen count as the only measure.
Integrations
Identify each system, available interface, data owner, exchange direction, and update schedule. A documented API with a test environment is different from an undocumented export that changes structure. Authentication, error handling, reconciliation, and integration testing belong in the scope.
Migration and synchronisation
A historical import transfers agreed records. Synchronisation keeps selected data aligned over time. Your project may need both while old and new systems operate together.
The estimate should cover mapping, data cleanup responsibilities, duplicate rules, sample migrations, validation, cutover, and recovery. The size of a database alone does not describe these requirements.
Reporting
Name the decisions the report supports and the source of each measure. Agree formulas, reporting periods, access, filters, exports, and data freshness. Reusing an existing reporting tool still requires integration and validation work.
Quality and operation
Testing is not limited to checking individual screens. Complete workflows, access rules, failure paths, and operational requirements need attention. Make the relevant work explicit in the estimate rather than treating it as an unspecified final step.
Rollout and support
Consider who will use the first release, what training and documentation are needed, and how the transition will be supported. At Horizon Dynamics, paid support is a required part of the engagement after launch. The proposal should distinguish that support from warranty fixes for agreed defects, new development, client-paid hosting, licences, paid APIs and monitoring, with clear billing responsibilities.
Compare the two engagement models
An hourly team works at agreed rates. Compare the team composition, recorded work, expected effort, and how forecasts are reviewed. The lowest hourly rate does not by itself establish the lowest total cost.
A fixed-price module has agreed workflows, deliverables, assumptions, and acceptance criteria. Compare what is included and how new requirements are handled. A fixed module price cannot describe an unlimited or undefined product scope.
Agree the payment schedule and support terms in the proposal.
Estimated hours describe effort. The delivery date also depends on task order, specialist availability, access to source systems and client decisions. Ask for those dependencies alongside the estimate.
For each unresolved assumption, show how it changes the work and cost. For example, compare using an available API with building a new export process. Assign a review of the source documentation before choosing between them; an unknown cost should remain an open item, not a zero.
Compare proposals against the same release
Compare two example proposals for an order-management system. Both list customers, orders, reports and an accounting integration. One assumes clean source data and a single successful import. The other includes a migration rehearsal, rejected-record handling and reconciliation with accounting. Their module lists look similar, but they describe different work.
Before comparing totals, ask each supplier to clarify the same five points:
- The working outcome. Can an order move from intake to completion, including partial fulfilment, cancellation and approval exceptions?
- The integration boundary. Who provides access, owns field mappings and investigates a failed exchange? Are retries and duplicate handling included?
- The data transition. Which history moves, who cleans the source, how are relationships checked, and what happens if a rehearsal fails?
- The acceptance evidence. Which scenarios, access rules and report results must pass, who reviews them, and how are differences recorded?
- The operating period. Does the comparison include the same months of support, hosting, licences and paid APIs? Separate build cost from ongoing charges and identify what the client supplies.
An exclusion is not automatically a problem: your team may already own that work. It becomes a budgeting problem when neither side has assigned it. Record each item as included, client-owned, separately priced or unresolved, with a named owner and a decision needed before commitment.
Use the project brief template to give suppliers the same starting context. For data-heavy scope, include the migration worksheet or reporting definition template.
Compare proposals against the same scope
Use one worksheet per supplier. Separate included work, client responsibilities, priced additions and unresolved assumptions before comparing totals.
- A completed customer-import scope row
- Acceptance evidence, exclusions and decision owners
- Build costs and a consistent operating period
Editable text file (.txt)
Fill it in locally using a text editor or your own document. Share a non-confidential summary when you contact us.
How to use the module estimator
Solution Studio lets you explore modules and their interactions and shows an example budget for the set you choose. A proposal prices your own scope, integrations, data and support.
The Pricing & Process page shows three worked configurations. Open any of them in Studio to see the selected modules and change the scope. A narrower example can sit below the USD 50,000 starting budget for a full custom project because scoped work can be priced separately; neither figure is a client quotation.
The shared foundation is counted once, required modules are deduplicated, and the example CRM import is not added twice when the migration module covers it. A real proposal must also validate the complexity of the connections: drawing another line on the canvas does not price an integration.
Read a complete planning example
The build and twelve-month operating example separates assessment, detailed design, modules, data transfer, the accounting interface, release checks and launch. It adds paid support and allowances for infrastructure and paid APIs. It spans the build plus twelve months after launch, not the first twelve months after signing. Taxes, contingency and later changes are excluded explicitly.
Prepare a useful estimate request
Share the business goal, current systems, main workflows, users, examples of data, constraints, and first-release priorities. Identify a business owner who can clarify the process and review the result. If an area is unknown, record it as an assumption to investigate.
You can send a project brief, explore custom CRM or custom ERP development, or review the Global Business Assistant case for an example of connected operational scope.
