What affects the cost of bespoke software?

Workflows matter more than screen counts.

A screen count can help describe an interface, but it does not capture every rule behind it. Access permissions, approvals, exceptions, calculations and the relationships between records can all change the amount of work.

Start by agreeing the essential end-to-end workflow. Features that do not support that first useful outcome can be considered separately. This is a way to clarify a project, not a guarantee that every small-looking request will be inexpensive.

Existing systems create dependencies.

An integration may depend on another vendor's API, a particular account plan or permission from an administrator. Investigating those constraints is different from implementing a connection whose behaviour is already well understood.

Data migration has its own questions. Where are the records now? Are duplicates and inconsistent fields present? Who can decide which records are correct? Importing a file and reconciling uncertain business data are not the same task.

• Access to the necessary systems and documentation
• Quality, volume and ownership of existing data
• Provider charges or account-plan requirements
• How failures and changes will be handled

Testing and handover belong in the scope.

Agree the review and testing work that the project needs. Permissions, accessibility, important failure cases and the supported devices should be considered according to the system's purpose, rather than being left as an assumption at the end.

Documentation, deployment, training and handover can also require time. A lower estimate is not necessarily better value if it excludes responsibilities that another proposal includes. Ask both suppliers to identify those boundaries clearly.

Separate building costs from running costs.

Hosting, third-party services, maintenance and support can continue after an application is launched. Their amounts depend on the technology, usage and agreement. A proposal should distinguish one-off work from recurring charges and explain who pays each provider.

Future changes are another consideration. Ask how requests are assessed, how updates are released and what information or access you receive if you later change supplier. Do not assume that a development fee buys unlimited changes or ongoing support.

Ask for the assumptions behind the number.

A practical estimate identifies what the supplier understands, what still needs investigation and what would cause the scope to change. If a deadline is important, explain its reason and discuss the minimum useful version rather than quietly treating every feature as essential.

• What exactly is included in the first version?
• Which dependencies or assumptions are unconfirmed?
• What review input is needed from our team?
• What is excluded, and what costs recur?
• How are changes and handover handled?

Start with a clear description, not a guess at a price.

We have not put a universal price range in this guide because it would not describe every project honestly. Explain the workflow, existing tools and constraints so the relevant work can be assessed.

Where there is an agreed spending limit, say so. It may help narrow the first version or reveal that an existing product is a better fit. A useful next step should make the decision clearer, not pressure you into a larger build.