Ziplyne Inc.

I joined Ziplyne in May 2021 as an intern, two months out of my degree, and I am still here.

Ziplyne sells digital adoption software. The short version: step-by-step guidance that runs on top of enterprise applications a company already uses — SAP, Workday, ServiceNow, Coupa — so an employee learns the system inside the system, rather than in a training session they will have forgotten by the time they need it. Later the company added test automation to the same platform, on the argument that guidance and testing are the same problem seen from two ends: both need to know what a workflow looks like and both break when it changes.

When I started, my work was the Dashboard's front end and the templates every guide is built from.

Two months in, the internship became a full-time offer.

The thing that actually widened what I was responsible for was not the title. It was moving past the front end — within months I was writing the REST endpoints behind the Dashboard, then the integration services that pull live data out of Coupa and Workday, then a Redis caching layer that roughly halved the database calls as client deployments grew. Nobody reassigned me to any of it. The work needed doing and I was the person there.

That pattern repeated for five years, and it is the honest description of how I ended up owning what I own.

Everything Ziplyne ships runs inside somebody else's application, and those applications change without telling us.

A vendor ships a quarterly release. A class gets renamed, a button moves into a shadow DOM, a page gets wrapped in another iframe. Every guide anchored to that element breaks — in production, at a customer, usually discovered by the customer. That is the constraint the whole job is organised around, and it is not one you can engineer away permanently. You can only make the system better at surviving it.

On top of that, three products had each grown their own way of identifying an element on a page. The same process could work in one and fail in another, and nobody could tell you why without opening all three.

The decision I am most attached to is that element identification became one shared package rather than three implementations. If a customer is ever going to move a process between products — which is the direction the whole platform was heading — then all three have to agree about what an element is. One source, consumed everywhere, versioned and released like any other dependency.

Inside it, I chose to make finding an element a fallback chain rather than a lookup. Stored selectors first. If those fail, a heuristic pass over the semantic HTML and the visible text. If that fails, visual comparison. A single strategy is a single point of failure, and in an environment you do not control, everything is eventually a point of failure.

The part I would argue hardest for is self-healing: when an element has moved and we find it another way, the package rewrites what it stored. Otherwise every recovery is temporary and the same guide breaks again next release.

On the process recorder, I kept its data structure identical to the guidance product's. It was more work at the time and it is the only reason processes can migrate between them now.

As a Software Engineer: the Dashboard front end and the guide templates, then the endpoints and integration services behind them, then the Redis caching layer. I rewrote the Player UI — the surface end users actually see — for re-render performance and cross-browser consistency, profiled rather than guessed at. I took on ZipRPA while it was still a desktop application and added Coupa integration, a scheduler, and data-driven testing that moved test data out of code and into spreadsheets a client controls, which is what let non-engineers write their own test data.

As a Senior Software Engineer: the shared element-resolution package described above, which took guide breakage from a weekly occurrence to near zero. The process-recording extension — capture, screenshot editing, per-step content, role-based sharing with SI partners, exports to HTML, PDF and JSON, and a public view page. The Creator redesign, which I owned end to end and alone: the design itself using Claude as the design tool, then the documentation, the Jira breakdown, the delivery timeline, and the production deploy.

And ZipRPA from a desktop tool to a cloud platform, 0→1 to production, leading three of the company's five engineers on it. Test execution moved off individual laptops onto shared infrastructure, with sequenced flows, rebuilt analytics, and integrations into Slack, Teams, email and Coupa. On top of it we shipped the AI layer: agents that crawl a customer's application and author its test cases with no human input, severity triage on every failure, and one-click repair that fixes the broken test instead of handing back a stack trace.

I started as an intern maintaining a template. I now lead engineering on a product and own the layer all three products depend on to find their way around applications we do not control.

What I am building at the moment is Trifecta — the migration path that lets a recorded process move between all three products in any direction, so a customer who onboards into one is never locked out of the others. It is the reason the shared package had to exist, arriving about two years after the package did.