A healthcare website quote needs more than a page count
%20(1).avif)
Written by Derrick KityoTwo healthcare website quotes can describe different jobs. Compare the responsibilities, content and connected services before treating the totals as comparable.
Two quotes can both say “healthcare website” and describe very different jobs. One might cover public pages linked to an existing booking service. Another might include several languages, a resource library and new enquiry connections.
Comparing the totals without comparing those responsibilities won’t tell you much. I’d first ask each supplier to explain what the website will do, what it relies on and what your team will need to provide.
Start with the boundary of the website
Separate public information from systems that deliver care or run the product. A marketing site, patient portal and clinical application may appear in the same initial conversation. They need different scopes.
Ask whether the quote includes linking to a booking provider, embedding its interface or building a new connection. Those choices change the work. Include who owns the provider account and who will help test the complete route.
For a healthtech site, define whether product demonstrations are prepared marketing assets or live access to the application. A demonstration request form is a smaller commitment than a system that provisions accounts and handles product data.
Put those decisions in the website brief template. A paragraph explaining the boundary is more useful than an extra list of desired animations.
Count content types and responsibilities
Page count tells you something about the content workload. It doesn’t explain how many different templates, relationships and review processes the site needs.
A service page and a research publication may use very different information. A resource hub might need authors, topics, related resources and review dates. Work out which content already exists, which needs rewriting and which needs a qualified reviewer.
My WithPower content-hub work involved separate collections for guides, publications, podcasts and case studies. That’s a useful example of why “a blog” can be an incomplete description of the job.
Content entry matters too. Does the supplier move existing material, provide a template for your staff or only build the CMS? Who checks that images, links and downloads survived? Put the answer in the quote.
Compare two clearly different briefs
These are fictional scoping examples, not client projects or price estimates.
Work to agree: Main audience task
Clinic public website: Understand services and reach the existing booking route
Healthtech marketing and resource site: Understand the product, explore evidence and request a discussion
Work to agree: Publishing
Clinic public website: Service, team and location information
Healthtech marketing and resource site: Product pages, resources and approved use cases
Work to agree: Connections
Clinic public website: Existing booking provider and an agreed general-enquiry route
Healthtech marketing and resource site: CRM handoff and any approved shared content source
Work to agree: Review
Clinic public website: Service owner and clinical wording reviewer where needed
Healthtech marketing and resource site: Product, evidence and language owners
Work to agree: Handover
Clinic public website: Staff changing practical details
Healthtech marketing and resource site: Editors maintaining several content types and releases
Neither column specifies patient accounts or the clinical product itself. If those are needed, scope them openly rather than expecting the website estimate to absorb them.
A supplier can now ask useful questions about either brief. They can also say which assumptions would change their estimate.
Want to apply this to your own website or app?
Tell me what you are working on and where it is getting stuck. I will help you turn the useful ideas into shipped work.
Ask where review time appears
Healthcare copy may need more than a marketing approval. Agree who checks clinical statements, personal-data handling and any regulatory wording relevant to the organisation.
The NHS content policy shows how NHS.uk separates editorial work from clinical approval. Your organisation needs its own suitable responsibilities. A developer’s delivery plan shouldn’t assume that approval will happen automatically.
If the site has several languages, ask who supplies and approves translations. Include the process for later changes. A translated launch followed by unowned updates leaves your team with a continuing job the original quote may not describe.
Allow for review rounds based on real material. Approving an empty layout doesn’t establish that a long service name, an evidence table or a booking notice will fit and remain understandable.
Include verification and the handover
A quote should explain the journeys that will be checked and who takes part. Those might include mobile navigation, keyboard use, enquiry delivery, document access and redirects from the current site.
The W3C forms guidance is a useful reference for form labels, instructions and feedback. Ask what the proposed accessibility assessment actually covers. Avoid treating the word “accessible” as a complete specification.
Handover should use tasks your staff will perform. Have someone change a service detail, replace a resource and find a failed enquiry in the agreed process. Record what they need help with.
Agree ownership of domains, hosting, CMS access, connected accounts and source files where applicable. Include the support route when the usual editor or developer is unavailable.
Separate the build from the cost of running it
Ask for recurring services and account assumptions alongside the delivery price. These could include publishing, translation tools, booking services, integrations and ongoing support. Use current supplier terms rather than an old article’s platform prices.
Make the responsibilities visible even when your organisation already pays for a service. An existing subscription doesn’t tell a developer which access is available or whether another team must approve the connection.
If the brief also includes a new application, my web app cost planner can help explore product scope separately. Its indicative model isn’t a quote for a healthcare website or evidence that clinical software will cost a particular amount.
Ask suppliers to explain the differences
When the quotes arrive, mark the work each one includes, excludes or leaves dependent on another decision. Ask about the gaps before negotiating a total.
A lower price can be sensible if your team will prepare the content or keep an existing service. It becomes hard to compare when that assumption is hidden.
For a focused review, share the current site, the proposed audience journeys and the two scopes you’re comparing. My healthcare website work covers public sites and publishing systems, with the responsibilities agreed around the organisation’s team.
Frequently asked questions
How much does a healthcare website cost?
The cost depends on the agreed scope. Compare content types, review responsibilities, languages, integrations, migration, verification and handover before comparing prices. A public website linked to an existing booking service is a different brief from a patient portal or clinical application.
Should hosting and ongoing support be included in the build quote?
They should be explained, whether they are included or priced separately. Ask which accounts and services the site needs, who pays for them and what support is available after launch. Check current terms with the relevant suppliers.
Does using an existing template remove the need for healthcare review?
No. A template can reduce some design and implementation work. It doesn’t approve clinical wording, establish appropriate data handling or test the organisation’s actual booking and enquiry journeys.
.jpg)
