MCPH · A founder’s case study
Rebuilding MCPH
around its readers.
MCPH was already an established site. I wanted to make it easier for patients to find useful information, improve the articles and give the agents helping me a clear set of rules to follow.
Starting pointExisting brand & WordPress site
AudienceUK medical cannabis patients
The workNavigation, articles & reference pages
How I organised the workProject intelligence layer
01 / Understanding the existing site
First, I needed to know
what I was working with.
MCPH is a patient-led information site. Its readers arrive with practical questions about records, appointments, terminology and the day-to-day admin around prescribed medical cannabis.
In June, I took stock of the existing WordPress site: its pages, article types, links and publishing rules. I recorded how they fitted together so an agent could find that information without piecing it together from old conversations.
Before an agent changed a page, I wanted it to know who the page was for, what it should help them do and how it connected to the rest of the site.
02 / Making information easier to find
Help readers find
the answer they came for.
I made the Patient Guide the main starting point. It brings together information about appointments, safety, conditions and the terms patients come across.
The idea was simple: someone arriving with a question should be able to find a useful guide, then follow links to anything else they need.
I also made the distinction between MCPH and Strains clearer. MCPH focuses on patient information. Strains covers cultivar history, photography and reviews. That helped me decide where each piece of content belonged.
03 / Improving the content
Make each page
useful in its own right.
In August, I turned to the reference pages. The cannabinoid and terpene entries had become too repetitive. On 8 August, they were rewritten using research specific to each subject.
Each page needed to explain what the substance is, what researchers have studied and what its name means on a label. It also needed to be clear about what the evidence could not tell the reader.
On 10 August, I worked on the homepage, condition pages and writing across the site. Repeated caveats and wording meant for internal notes were getting in the way. I wanted the information to be clear and direct, with limitations explained where they mattered.
04 / Keeping later work consistent
Keep the decisions
with the project.
I kept a record of the site structure, who it serves, how the writing should sound and what needs checking before publication. This is MCPH’s project intelligence layer. Agents are told to read it before they start and update it as the site changes.
It’s the same approach I’ve packaged into IntelligenceOS: give the agent a map of the project and clear instructions it can return to. I still had to make editorial decisions, review the changes and check them on staging before publishing.
With Strains, I used the kit to start a new build. MCPH was a different challenge: I had an existing brand and a working site, and I wanted to improve them without losing what was useful.
The aim was a site that was easier for readers to use and easier for me to keep improving with agents. Recording the decisions gave each new session something to work from.
Already have a project?
Make your existing project
easier to work on.
IntelligenceOS can map supported local project files and help your agent understand what exists, what is unclear and what to work on next. You decide which changes to make.
Based on my project notes from June to August 2026. The screenshots are cropped from the live site on 7 September 2026. This is my account of the rebuild; I haven’t measured its effect on traffic or patient outcomes.