MDR replacement landing page
first look, options & open questions

Alberto sent over the MDR page he built in Claude Design for Liz to explore deploy options. TLDR; it looks good, but we learned it isn’t plain HTML — it’s a small React app, which changes where it can sensibly live.

What we found

It’s a React app, not a static page

• One 7.6 MB file is a self-extracting bundle. On load it unpacks in the browser into a client-side React app (React 18 plus a few helper scripts).
• Every asset is embedded. Fonts, logos, and photos are all packed inside the file — no external asset folder, no broken links. It’s fully self-contained.
• It renders faithfully. The export is complete; nothing is missing visually.
• It expects to own the whole page. The app uses global styles and element IDs, so dropped inside a themed WordPress page it collides with the theme. That’s why it isn’t a paste-into-a-block job — not a size limit.

Live preview

To do

Still in progress

This project is mid-design, so a couple of things are still ahead — flagging them so they’re accounted for before go-live:

• Mobile view It’s desktop-only right now, with no mobile layout yet. A mobile pass — easiest back in Claude Design — is needed before it goes public.
• Form and CTAs These still need wiring up once their destinations are decided.

Where it could live

Options

Our lean

To settle soon

A few calls that shape the build

With a go-live target of late next week, these are worth locking down early — each one changes how the page gets set up:

• Role in the marketing flow Is this paid-campaign traffic, an organic page meant to rank, or both? It sets what the page is for, and it decides whether the page should be indexed and built for search at all (paid pages are usually kept out of Google).
• Should it link back to ontinue.com? Right now the page is nearly a dead-end — the only links off it are the customer case studies (out to PDFs on ontinue.com, in a new tab). Decide whether it should offer any way back to the main site (a nav, a “learn more,” a footer) or stay self-contained to keep focus on the form. If it does link out, that’s what triggers the cross-domain tracking noted in the checklist.
• Form destination Most likely a Marketo form, since that’s what Ontinue uses across the site. Worth confirming which form / program it feeds, that spam protection (honeypot or invisible reCAPTCHA) is on so a fresh subdomain doesn’t get flooded with fake leads, and that consent and pre-fill behave the same as on ontinue.com.
• Ownership & hosting Who owns the repo, the Vercel project, and the domain long-term — this shapes how we hand it over.
• Hosting platform & approval Since nothing in the current stack fits, the first real call is which platform hosts the live page and how fast InfoSec can clear it. That approval — not the build — is the critical path to the date.

Pre-launch checklist

Smaller details worth covering

The smaller pre-launch details worth covering before go-live, whoever ends up building it. We’re happy to take these on if that’s WHM:

• A real web address Live at an Ontinue URL (e.g. mdr.ontinue.com), not a temporary link. Setting DNS can be an IT ticket, so worth starting early — and confirm whether they accept Vercel’s automatic SSL or require their own certificate.
• Performance Unpacking the export into normal files already removed the original load delay; compressing the large images (~1 MB each) is the remaining win. Deeper build optimization would need Alberto’s source, not the exported build.
• SEO & indexing A deliberate call on whether Google should list this page (paid pages are usually hidden so they don’t compete with ontinue.com). If it should rank, it needs a proper title, meta description, and Open Graph tags, plus a real domain rather than a *.vercel.app URL.
• Analytics & tracking A standalone deploy won’t inherit ontinue.com’s GA4 / GTM setup, so conversion tracking and UTM attribution have to be added deliberately. If the page links back to ontinue.com rather than being a dead-end, it also needs cross-domain tracking or the paid attribution is lost.
• Cookie consent (OneTrust) The site’s OneTrust banner won’t carry over automatically. The new domain needs adding to OneTrust and re-scanning, and its consent rules typically gate GTM, analytics, and the Marketo cookie — so this and tracking go hand in hand.
• Legal links Privacy, terms, and OneTrust cookie preferences — expected on a page that collects data. The design has no footer yet, so it’d need a small footer or link row to house them.
• Form opt-in Marketing-consent handling — already built into your standard Marketo form, so you carry it over by using that form.
• Accessibility Screen-reader and keyboard support, contrast, and reduced-motion.
• Favicon The export ships a generic one; needs the Ontinue mark.

How WHM can help

However you want to run it

We want this to launch smoothly and leave your team able to own it. A few ways we can help:

• Hosting the preview We can keep the working preview live on Vercel and redeploy it each time Alberto sends an updated HTML export, so there’s always a current link to review.
• Deployment, ready to hand over It’s already in a Git repo wired to Vercel, so it redeploys on every push. We can transfer the repo to Ontinue whenever you’re ready — or keep running it in the meantime.
• A short walkthrough for Alberto A quick session on using GitHub and Claude Code to edit and redeploy the page directly, so iterating on it doesn’t have to route through us.
• QA before launch Our dev team can run it through cross-browser and device QA before go-live.