Situation
A platform built elsewhere, and nobody arriving to use it
The marketplace lets a patient find and book the soonest open appointment across physiotherapy, massage, chiropractic, counselling and related disciplines. Availability is gathered automatically from clinic booking systems, so the supply side was full from the start. A patient who found the site could book.
The platform had been built and hosted by another vendor. The client decided to end that arrangement and bring the whole thing under one roof. The handover had to happen without the site going down, because the clinics listed on it did not know or need to know who was hosting it.
The second problem was demand. The growth strategy we delivered to the client in May 2026 said it plainly: the constraint is demand, not product and not supply. The clinics were already indexed. Patients were not arriving. The prescription was inbound. Capture the local search demand that already exists, with pages generated from the clinic data the platform already held, then give a patient a shorter path from a problem to a booking.
What we built
Take it over first, then build the front door
The takeover came first. We received the source code, the transition documents, the database export and the scraping environment, audited all of it, and wrote an inventory of what had transferred and what was missing. The code moved into a repository the client owns. Hosting moved onto a managed stack we run for the client. Domains and DNS transferred. Every inherited credential was rotated and put under least-privilege secret management. The availability pipeline was verified live under our operation before anything else was touched. The handover snapshot was committed on 2026-06-09. The first region went live 8 days later.
Then the front door. A programmatic local-SEO engine generates a page for every clinic from the data the platform already holds, plus treatment-in-city service pages, walk-in pages and guides. Each page carries its own written copy, structured data for search engines, internal links, and a refresh from the current availability signal for its area. The engine publishes an XML sitemap and submits it for indexing. Competitors hand-write local pages. This client generates them from data it already owns.
Three features sit on top of the pages. A symptom-to-appointment finder: a patient describes the problem in plain words, the finder maps it to the right treatment and shows the soonest nearby openings. Waitlist alerts: a patient asks to be told when openings appear near them, and the system emails when they do. And a growth dashboard on the client's own login, showing traffic, top searches, alert sign-ups, and the count of pages live and indexed.
How it runs
One data set, published province by province
The availability pipeline gathers clinic openings on a cycle and writes them to the client's database. The SEO engine reads that data and regenerates its pages from it, so a page is never older than the data underneath it. A routing layer in front of the domain sends the generated pages to the static site and everything else to the booking application. The two ship on their own schedules without touching each other.
Launch went province by province. British Columbia went live on 2026-06-17. Alberta followed by 2026-07-15. Ontario went live on 2026-08-05. Each launch was a merge, and each one reads from the same dashboard the client already had open.
The client owns all of it: the migrated code, the generator, the connectors, the documentation and the architecture notes we wrote during the takeover. If the client changes vendors again, the next vendor inherits a documented system instead of a mystery.
What we measured
Pages published, provinces live, and what we will not claim yet
On 2026-08-20 the published sitemap held 9,437 URLs. 8,717 of them are clinic pages. 609 are treatment-in-city service pages. The rest are walk-in pages, guides and near-me pages. Every one was generated from data the platform already held.
The first region went live 8 days after the handover commit. Three provinces were live by 2026-08-05.
What we do not print: search impressions, clicks, bookings or revenue. The dashboard records impressions and clicks from search, and we are not publishing them yet. Click-throughs to a clinic's booking page are not recorded in the database at all, so there is no booking count to print. The first number is due October 2026, once the dashboard records click-throughs.
A page count is a build number, and we label it as one. It says the engine works. It does not say the engine pays. That second claim waits for the measurement that would earn it.