In June we shipped the feature I'd wanted since day one: press Record, do a task in any web app, and Guidely turns your clicks into an interactive walkthrough your team can replay, live, on the real tool.

It worked. It passed our test suite. The demo was great.

Two weeks later I commented out the Record button.

This is a post-mortem, partly because writing it down forces me to be honest about what happened, and partly because everyone building on top of other people's web apps eventually hits this wall, and I couldn't find a single honest write-up about it when I needed one.

What we built

The naive version of a recorder saves a CSS selector for every click. Everybody's first version does this, and everybody's first version breaks the moment the target app ships a redesign, or renders a slightly different DOM for a different user, or just uses generated class names like css-1x2ab9.

So we didn't build the naive version. We built the paranoid version:

Every recorded step captured a whole descriptor: an ordered ladder of locator strategies (test id, then id, then ARIA role plus accessible name, and so on down to XPath as a last resort), plus a fingerprint of the element's text, neighbors, and position.
At record time, the recorder immediately tried to re-find each element it had just captured. If it could only get back to the element by position — "the fourth button of this type" — it flagged the step as fragile instead of pretending everything was fine.
Playback pierced shadow DOM and same-origin iframes, waited for elements to actually be clickable the way Playwright does, and scored candidate elements on multiple signals instead of trusting one selector.

I'm still proud of that engine. It passed 32 tests, including a nasty one where a page re-renders its whole shadow DOM between recording and replay.

And none of it was the actual problem.

Where it actually broke

The problem wasn't finding elements. The problem was that replaying human actions on someone else's app is an act the app is allowed to refuse.

Google Calendar was the first to refuse. Our player originally performed clicks for you during a walkthrough — synthetic click events on the highlighted element. Calendar's event dialog took one look at our synthetic click sequence and closed itself. Not an error. Not a broken selector. The app just behaves differently when the click isn't a real, trusted, user-initiated click, and it's fully within its rights to.

We fixed that one, actually, and the fix taught us something: stop clicking for the user. Dim the page, spotlight the real element, and let the person click it themselves. A real click from a real human is the only input every app respects. That principle survived and is still how Guidely works today.

Then monday.com introduced us to hover-cascade menus: submenus that only exist while a pointer is floating over their parent. Our recorder captured clicks, inputs, and navigation. It did not capture "the user hovered here for 400 milliseconds, which conjured a menu out of nothing." So the recording had a hole in the middle, and a replay can't spotlight an element that doesn't exist yet.

Each of these was fixable. That was the trap. Every single failure, in isolation, had a fix, and after the fix the demo worked again. What finally sank in was the shape of the whole thing: every web app is a new adversary. Google has its event model, monday has its menus, Salesforce has whatever Salesforce has. And even when you win, you've won against today's build of the app. Recordings rot. The insurance company updates their claims portal on a Tuesday and forty guides break silently, and your customer finds out when a new hire gets stuck on step 3 of "How to file a claim."

A feature that's 95% reliable sounds close to done. For training software it's actually poison, because the person following the guide is, by definition, someone who doesn't know the app. When the guide breaks, they can't tell whether they broke it or you did. They just learn not to trust it.

The call

So in early June I made the call: shelve it. The Record button is commented out. The engine — all of it, the descriptor ladder, the self-verification, the shadow DOM piercing — sits dormant in the codebase.

Sunk cost screamed. Months of work, a genuinely hard engineering problem, mostly solved. But "mostly solved" was exactly the issue, and there was a second thing that made the decision easier: we had another path that didn't have this failure mode at all.

Instead of replaying a recording of the past, Guidely's AI looks at the page right now and figures out the next step live. Ask "how do I add a contact to this deal?" and it reads the current DOM — today's build, your account's layout, your permissions — and points at the actual element in front of you. There's nothing to rot, because there's no recording. If the app redesigns itself tomorrow, tomorrow's answer is based on tomorrow's page.

The irony is that the recorder work is what makes the live path good. That elaborate element-finding engine we built for replay? It now powers how live guidance locks onto elements in shadow DOM and dynamic UIs. The self-verify idea — never silently accept a fragile match — became a rule for the live system too. We shelved the feature and kept the muscle.

What I'd tell you if you're building on top of other apps

Test on real apps brutally early. Not your test page. Not a to-do demo. Google Calendar, monday, Salesforce — the apps that have spent a decade accumulating defensive quirks. Our engine passed every test we wrote and the web still won, because the tests were a model of the web and the web is not obligated to match your model.

And when you find yourself fixing an endless series of individually-fixable bugs, stop and ask what the series converges to. Ours converged to "a permanent staff of one full-time engineer per popular SaaS app, forever." That's WalkMe's business model, roughly, and it's why WalkMe deployments cost six figures. It was never going to be ours.

Killing the feature didn't shrink the product. It's the reason the product works.