Custom software development has no single reliable price. The cost depends on the workflows, integrations, data, quality requirements and operating support included. A defensible estimate starts with a defined scope, calculates delivery effort at an agreed rate and separately budgets migration, third-party services, contingency and ongoing ownership.

For a concrete illustration, 126 delivery days at an assumed blended £550 per day produces a £69,300 delivery budget before contingency, VAT and separately scoped costs. Neither the rate nor the effort is a market benchmark or a HINTX quotation. The worked model below shows how to interrogate a proposal rather than promising a price before the requirements are known.

Define what the estimate is buying

A request for “an internal portal” can mean anything from a few forms to a multi-team operational system. Describe the users, business transactions, approval rules, reports and external connections. Specify what happens when a record is rejected, a payment fails or someone loses access.

Agree what completion means. Does the price include production deployment, documentation, staff training, historic data import and a support period? Who supplies content, test data and business decisions? Two quotations cannot be compared fairly until these boundaries are visible.

GOV.UK's discovery guidance supports investigating users, constraints and the problem before deciding to build. A commercial discovery should reduce expensive uncertainty and may conclude that configuration or an existing product is sufficient.

The cost drivers that usually change the estimate

• Workflow complexity: branches, exceptions and permissions require design and validation beyond screen construction.
• Integrations: API quality, authentication, usage limits and access to test environments affect effort.
• Data migration: duplicates, missing fields and conflicting identifiers require agreed resolution rules.
• User experience: mobile layouts, accessibility and complex operational tasks need appropriate design and testing.
• Operating requirements: availability expectations, recovery, audit history and support coverage change the delivery scope.
• Decision speed: delayed feedback or changing business rules can extend calendar time and introduce rework.

A short feature list can conceal substantial complexity. “Approve order” may include delegated authority, monetary thresholds, revisions after approval and a complete decision history. Ask the supplier to estimate representative scenarios rather than relying only on a count of pages.

A transparent illustrative delivery budget

Assume a bounded internal web platform with three staff roles, one main workflow and two documented integrations. These are invented planning assumptions, not a completed client estimate. The 126 days represent total team effort, not 126 consecutive calendar days.

An illustrative 15% contingency adds £10,395, producing £79,695 before VAT, infrastructure, third-party licences and ongoing support. The percentage is a modelling choice, not a recommended allowance for every project. Estimate known risks explicitly; do not use contingency to conceal features everyone already knows are required.

Check whether a supplier's day rate already includes coordination or quality assurance so you do not count them twice. Conversely, a low development-only estimate may leave the buyer to fund essential work elsewhere.

Model uncertainty instead of hiding it

Give uncertain work a range and a reason. A well-documented integration with a sandbox is different from a legacy system whose data can only be exported manually. Commission a short technical experiment when it can materially narrow the estimate.

For the illustrative project, an additional 20 delivery days at the same assumed rate would add £11,000 before any contingency adjustment. That sensitivity is more informative than presenting the original number as fixed when the integration is still unknown. Record who can approve scope changes and how revised estimates will be communicated.

Include quality as planned work

Security review, access-control tests and vulnerability handling should have named responsibilities. NIST's Secure Software Development Framework provides a reference for discussing these practices with a delivery partner. It does not make a project secure simply because a proposal mentions it.

Accessibility also needs explicit requirements and verification. W3C's WCAG overview explains the web accessibility standards. Agree the relevant target and testing approach, including keyboard operation and representative assistive-technology checks where appropriate. A template choice is not evidence that the finished application meets the target.

Budget for the system after launch

Separate operating costs from future feature investment. List hosting, backups, monitoring, software licences, external API usage, support, dependency updates and internal administration. Specify support hours and response arrangements, because “maintenance included” can mean very different things.

Use a monthly model based on expected workload and test a higher-use scenario. A messaging or AI integration may incur variable charges. Confirm the charging unit with the provider and set appropriate monitoring; do not bury variable consumption inside a supposedly fixed infrastructure figure.

Plan for an eventual exit too: exportable records, deployment documentation and access to the source repository reduce avoidable transition work. Ownership arrangements should be clear before implementation begins.

Reduce scope without undermining the outcome

Start with one complete operational journey. Defer optional reports, additional channels and cosmetic variations when they do not affect the first users' ability to complete work. Keep the permissions, data integrity and recovery behaviour necessary for that journey.

HINTX's LegalPDF portfolio describes a focused document conversion workflow. MiaFour spans several connected operational areas. These examples illustrate different scope shapes; their project prices and delivery durations are not disclosed or inferred here.

Our custom software and SaaS development service starts with agreed workflows and acceptance criteria so estimates can be reviewed against the intended operation.

Frequently asked questions

Can HINTX provide a fixed price immediately?

A meaningful proposal needs enough information about scope and risk. A bounded discovery or a clearly specified small deliverable can make pricing more reliable.

Are these current UK market rates?

No. Every figure in the worked example is an illustrative input. Obtain project-specific quotations and compare inclusions before making a purchasing decision.

Does AI-assisted coding remove most of the budget?

It may change effort on particular tasks, but requirements, integration validation, review and operational responsibility remain. Ask how productivity assumptions are reflected in the actual estimate.

What should a useful quotation show?

Scope, assumptions, exclusions, effort or milestones, acceptance criteria, dependencies, ownership, change control and post-launch responsibilities.

Request a scoped software discussion with HINTX. Share the workflow, users, integrations and launch constraints so the budget can reflect real requirements.