Skip to content

Musha Healthcare / Website rescue case study

Recover the website. Restore the journey.

A care-service website rebuilt around clearer service information and contact routes.

Project
Musha Healthcare
Project period
2026
Archive
8 captured screens
Material
3 comparison views
Musha Healthcare homepage
Project archive · July 2026 · Homepage with care services, contact details and enquiry routes.

Inside the project / An interactive reading

The story behind the screen.

Website rescue case study — explore the context, material and responsibilities of this project. No invented KPIs or endorsements.

01 / 03

Musha Healthcare / The challenge

Understand the problem.

Rebuild the public experience without relying on the inaccessible original hosting account, while keeping essential service and contact information clear.

Evidence in this chapter

  • 01The project began with a website access problem and a need to reorganise the public information for families and care professionals.
  • 02A care-service website rebuilt around clearer service information and contact routes.
Start a related project brief ↗Explore project evidence ↓

The context

Musha Healthcare

The project began with a website access problem and a need to reorganise the public information for families and care professionals.

The job to do

Rebuild the public experience without relying on the inaccessible original hosting account, while keeping essential service and contact information clear.

The approach

Rebuild the website, give individual services their own routes, and organise the content around how families and professionals look for care information.

What the project brings together

  1. 01

    Independent website rebuild

  2. 02

    Dedicated care-service pages

  3. 03

    Clear family and professional contact routes

  4. 04

    A planned domain changeover

Evidence-led outcomes

A visible change, not an invented metric.

The experience now brings together
Independent website rebuild. Dedicated care-service pages. Clear family and professional contact routes. A planned domain changeover.
The evidence available
Interface captures from July 2026, the recorded scope and original and rebuilt comparison views. These do not establish measured revenue, adoption or conversion results.

Documented change

Original & rebuild.

Homepage

New Musha Healthcare homepageOld Musha Healthcare homepageOriginalRebuild
Original and rebuilt homepage views from the project archive.

Archive captures · July 2026. Screens are cropped to the same viewing frame. Current live sites may have changed.

Project archive / Delivery notes

Design decisions

  • Rebuild independently: no reliance on the old hosting account the client had lost access to
  • Move the site onto the client's own domain via a coordinated DNS changeover
  • Lead with trust: CQC-regulated badge, 24/7 phone and address visible on every page
  • One clear page per care service instead of one long block of text
  • Neighbourhood-based care model given its own explanation, not buried
  • Warm, plain British-English copy: no clinical jargon, no filler
  • Enquiry and phone CTAs repeated at the natural decision points
  • Mobile-first layouts, since most families search from a phone

Recorded scope

  • Homepage rebuilt around the promise 'Quality care, done well'
  • About page covering mission, vision and values
  • Nine service pages: domiciliary, live-in, night, respite, hospital discharge, companionship, dementia, sensory impairment, supported accommodation for young people
  • How We Work page explaining neighbourhood-based care
  • Careers page for carer recruitment
  • Contact page with enquiry form, address and 24/7 phone lines
  • FAQ section covering coverage, CQC regulation, services and who they support
  • Full mobile-responsive layout and launch checklist
  • DNS changeover from the old temporary hosting URL to mushahealthcarelimited.co.uk

Evidence shown is the captured interface and the recorded project scope. Archive date: July 2026.

The standard behind the work

Designed to be used.
Built to be owned.

Delivery & acceptance ↗
01

A clear decision trail

Scope, assumptions, dependencies and changes recorded against the brief.

02

Evidence before acceptance

User journeys, permissions, failure conditions and operating requirements reviewed before release.

03

Ownership beyond launch

Source, documentation, training and recovery responsibilities agreed as part of handover.

Credentials & project assurance ↗

Start a conversation

Have a related brief?

Bring the current experience, the people it serves and the change you need to make.