Every project is different, but budget expectations should not be vague. Explore typical project ranges or use the estimator to understand the likely scale of your investment.
Indicative ranges. No hidden commitment. A detailed estimate is prepared after discovery.
Answer a few questions about the project. The estimate updates as you go — nothing is sent anywhere.
These figures are a starting reference, not a guarantee that every project fits within the published range.
Scoping, audit, roadmap and estimate for a project that isn't fully defined yet.
Workflow automation and system connections that remove a specific manual bottleneck.
A focused internal tool or operational application built around one team's workflow.
An authenticated portal for clients, suppliers or partners to interact with the business.
An initial product release built to validate a business idea with real users.
Audit, stabilisation and phased modernisation of an existing application.
Updates, fixes, monitoring and continuous development based on reserved development capacity.
Ten factors typically explain most of the difference between two projects that sound similar on paper.
Business process complexity
Number of user roles
Integrations and external APIs
UX/UI requirements
Security and compliance requirements
Data migration
Scalability and infrastructure
Delivery timeline
Documentation and handover requirements
Post-launch maintenance
The model that fits depends on how clear the scope already is, and how the project is expected to evolve.
For projects with unclear scope, legacy systems or technical uncertainty.
ResultValidated requirements, priorities, architecture direction, risks and estimate.
For focused projects with stable requirements and clear acceptance criteria.
ResultAgreed deliverables, timeline and price range.
For applications and products expected to evolve through user feedback.
ResultPhased releases, regular demonstrations and flexible prioritisation.
For ongoing development, maintenance and product evolution.
ResultReserved capacity, continuous improvements and long-term technical ownership.
Two applications that sound similar on paper can have very different workflows, data quality and integration risk. A single headline price would be more marketing than information.
Hidden integrations, undocumented business rules and inconsistent source data are the most common reasons a project's real scope differs from its first description.
A range is more useful than a misleading starting price — and discovery is what converts assumptions into a scope and estimate you can actually plan against.
Two projects that sound similar can have very different workflows, data quality and integration risk. A fixed headline price would be more marketing than information — ranges reflect that honestly.
No. It is an indicative estimate based on the characteristics you select. A quotation is prepared after discovery, once the scope is validated.
Discovery and audit engagements start around £500. Full development projects are generally most viable above a few thousand pounds — MURTWEB will say directly if a project looks too small to be delivered well.
Yes, when it is a dedicated engagement with its own deliverables. Short introductory conversations before that are not charged.
Where scope is clearly defined and stable, fixed-price delivery is possible. Larger or evolving projects are usually delivered iteratively instead.
Yes. Phased delivery is common for larger projects and lets you validate value before committing to the full scope.
Changes are discussed openly and reflected in scope, timeline and price before they are implemented — not discovered afterwards in an invoice.
Third-party costs (hosting, APIs, subscriptions) are identified separately and are not included in the development price unless explicitly stated.
Only where selected in the estimator or explicitly included in the proposal. It is priced separately because not every project needs the same design depth.
Client-specific source code is normally transferred according to the contract once obligations are fulfilled. See the Ownership & IP page for details.
Yes. Essential maintenance, business support and continuous development plans are available and shown separately from the initial project range.
Yes. Legacy modernisation projects typically start with a technical audit before any estimate is given.
Published figures should be treated as excluding VAT unless explicitly stated otherwise. The applicable tax treatment is confirmed in the commercial proposal.
Payment structure (deposit, milestones, monthly) is defined in the proposal and depends on the engagement model and project size.
It depends on current availability. A realistic start date is discussed during the initial conversation rather than promising immediate availability.
Tell MURTWEB what you are trying to improve, replace or build. The context will be reviewed and the most appropriate next step suggested.
Personal response within two business days.