SaaS apps change. Banners get added. Buttons get renamed. CSS classes get rewritten. Cap Artist re-runs your demo headlessly on every viewer session boot, detects what drifted, and asks Claude to find the equivalent element on the live page — before your prospect sees a single broken overlay.
If you’ve ever built a guided product tour, walkthrough, or onboarding flow, you know the silent killer: the underlying app keeps changing. A new feature flag ships. A designer renames a class from .btn-close to .dismiss-button. A banner shows up that nobody asked for. None of these break your app — they break your demo.
Sales engineers feel this most acutely. You spend a Friday afternoon building the perfect Acme Corp demo. On Tuesday, an engineer ships a tiny redesign. Your highlighted “Add new contact” button is now positioned 40 pixels lower. Your tooltip overlay points at empty space. The prospect asks “wait, where am I supposed to click?” and you’re explaining the gap instead of selling the product.
“Every guided demo is a maintenance liability. The demos that close the most deals are also the ones that break the fastest, because they’re built around the parts of the product that engineering changes the most.”
The traditional fixes are all bad. You can freeze the underlying app behind a feature flag for the demo (engineering hates this and it goes stale). You can maintain demo selectors by hand (one SE’s full-time job, in perpetuity). You can accept the breakage and re-record the demo every few weeks (the friction kills your demo cadence).
Cap Artist takes a different approach: the demo notices when it’s breaking and fixes itself.
Every time you build a guided demo step in Cap Artist Studio, the editor captures a rich baseline of every targeted element — not just one fragile CSS selector. It records:
id, stable data-* attributes, ARIA role + accessible name, a CSS path, and a text-content fallback.value and the like are explicitly redacted).This baseline is what makes self-healing possible. A single selector that breaks tells you nothing useful. A baseline that captures what the element was tells you everything you need to find it again.
When you share a viewer link and a prospect opens it, Cap Artist’s session boots in three phases that run in parallel:
The validator visits each step’s page, runs the non-mutating pre-demo actions you scripted (dismissing banners, scrolling, waiting for content — never submitting real forms), and tries to resolve each overlay’s target. It walks the stored selector candidates in rank order. If the id-based candidate still resolves cleanly, great — we’re done. If it doesn’t, we try the next. If none of them resolve, or if they resolve to something that doesn’t match the stored context, we have drift.
When the validator detects drift, Cap Artist asks Claude to find the equivalent element on the live page. This is a multimodal call — the prompt includes:
ElementContext baseline as structured JSON.Claude returns a structured response: a new CSS selector, a confidence score between 0 and 1, and one sentence explaining the choice. The prompt is enforced through Claude’s tool-use schema, so the response is always parseable.
Before Cap Artist trusts the proposed selector, it locally verifies the fix — runs the same drift check against the proposed selector to make sure it actually resolves to a viable element. AI proposals that look good but don’t resolve on the live page are flagged, not applied.
The threshold is calibrated conservatively:
expected_content_hash precondition (so it won’t clobber a concurrent human edit), and persists for every future session. The prior selector is kept on record so you can revert with one click.Either way, the owner gets one email summary — not one per overlay, not one per session. The email is deduplicated at the database level via a stable drift signature, so the same drift never sends twice.
Cap Artist demos aren’t meant to run on real customer accounts. The product’s data-faking infrastructure — the ruleset’s proxy rules — rewrites real values with synthetic data before the page renders. So when self-healing captures a screenshot or DOM excerpt, it’s capturing already-faked data. That’s the primary privacy guarantee, and it’s structural: capture and validation always run through the same rule-applying proxy session as the live demo.
On top of that, capture-time redaction strips input values, masks anything that looks like an email or phone number, and allowlists which attributes get stored. And self-healing is a per-demo on/off toggle — owners can pause it without losing their demo, and purge all healing assets for any demo with one click.
The end state is a demo that just keeps working. Your app ships a redesign — the demo notices, the AI re-finds the targets, the high-confidence fixes apply, and you get one email summary. You skim it, hit Approve on the flagged items, and you’re done. The hour you used to spend hand-patching selectors after every release is gone.
For the prospect, the demo Just Works. They never see the cleanup. They never wonder where they’re supposed to click. They see the polished story you built, every time, no matter what your engineering team shipped over the weekend.
AI self-healing is included in the Team plan ($129/mo, 5 concurrent viewer sessions). Toggle it on for any demo from the desktop app’s settings panel.