Why bespoke software does not have a standard price
Two systems with the same number of screens can represent completely different engineering problems. One may simply store records; another may coordinate approvals, calculate availability, integrate with external providers and maintain an audit trail.
The cost comes from the behaviour the software must reliably support, not from visual page count alone.
- Number and complexity of business workflows
- Different roles, permissions and approval rules
- Data model, migration and reporting requirements
- External services, APIs and authentication
- Operational tooling and support requirements
- Testing, security and resilience appropriate to the risk
The cost of replacing manual processes
A spreadsheet or email-based process can appear simple because people compensate for gaps with experience and judgement. Software has to make many of those hidden rules explicit.
During discovery we look for exceptions, hand-offs, duplicate data entry and decisions that currently depend on individual knowledge. Capturing those details early is one of the best ways to avoid budget surprises later.
Build versus buy matters to the budget
Bespoke development is not automatically the right answer. If a mature off-the-shelf product supports the workflow well, buying it can be faster and cheaper.
Custom software becomes more compelling when the business is spending significant time on workarounds, when several tools need to be coordinated, or when the process itself creates competitive or operational value.
How we would scope a first release
We would normally begin with the most valuable workflow and identify the users, data, decisions and integrations involved from start to finish. That becomes the backbone of the first release.
Features that do not help complete or validate that workflow can be separated into later phases. The result is a more defensible budget and a product that can start earning evidence sooner.