ZenRows

Turning traffic into a customer journey

ZenRows helps developers and businesses retrieve reliable web data from sites designed to resist automated access. The customer expectation sounds simple: provide a target and get useful data back. Delivering on it means dealing with access controls, changing site behaviour, product usage and infrastructure behind the scenes.

The distance between that simple promise and the complexity of the product makes activation especially important. New customers often arrive with a specific job to do. They need to find out quickly whether the platform works for their target, understand how to use it and gain enough confidence to put it into a real workflow.

When I joined the Activation team as technical lead in January 2026, ZenRows already served hundreds of customers each day. What it lacked was a dependable, shared view of how those customers moved from initial interest to sustained use. Product, engineering, growth and data could each see part of the journey, but not the same journey from end to end.

My first job was to connect those perspectives around one measurable path to value, then use it to decide what the product needed next.

Establishing a shared view of activation

The first major decision was to resist starting with a redesign. Before changing the experience, the team needed to understand it.

I mapped the journey from acquisition and onboarding through early success and ongoing usage, then designed the measurement system required to follow it across the product. Signals that had previously lived in separate services and team-level reports were brought into a coherent model, giving the business a common language for progression, friction and drop-off.

The architecture mattered, though the shared view it created mattered just as much. A growth question could be connected to product behaviour. A product observation could be checked against usage. Engineering work could be evaluated by its effect on the customer journey, not only by whether it shipped.

That changed the conversations we could have. Instead of debating isolated symptoms or extrapolating from the loudest support request, the team could identify where progress slowed, form a focused hypothesis and measure whether a change helped. Measurement became part of how the team worked, rather than a report produced after everything else was done.

Rebuilding the path to first value

With that foundation in place, I led the architecture and delivery of a new application experience. It was broader than a single feature migration. We brought several parts of the product onto a shared foundation, combining newly designed journeys with existing capabilities that were still serving customers well.

The in-product scraping workflow stayed near the centre because that is where customers test the platform's core promise. Around it, we rebuilt, adapted or carried forward other areas according to what each one needed. We kept proven behaviour, replaced genuine friction and worked to make the old and new parts feel like one product.

Billing was one piece of that wider programme. It received particular attention because changes touched active customer relationships and revenue, so continuity mattered as much as improvement. It became a useful test of the new foundation: meaningful change had to remain compatible with the stability expected from a business-critical surface.

The new foundation had to improve the experience without destabilising the product people already depended on. It also needed to create room for continued experimentation rather than hardening the first redesign into a new set of assumptions.

The work was organised into an eight-week delivery window. A basic working version was established in the first two weeks. The following month brought the experience to an initial group of customers. The final two weeks were reserved for adjustment—responding to real behaviour, refining the rollout and changing decisions that did not survive contact with use.

That cadence created urgency without pretending the first release would be final. Each phase had a clear job: prove the foundation, test it with customers, then improve what real use exposed.

Shipping as controlled learning

We treated the rollout as an experiment, not a launch-day reveal.

The existing and new experiences ran side by side through controlled feature flags, with traffic divided evenly and releases shipping each week. This gave the team a live comparison while protecting the wider customer base from a single irreversible launch.

Feature flags did more than control deployment. They gave the team a clear boundary for learning. We could observe how behaviour changed, separate the effect of the new experience from wider fluctuations and adjust the product while the evidence was still fresh.

It also lowered the cost of being wrong. A weak assumption could be corrected in the next weekly cycle instead of being defended because too much had been invested in a large launch. Progress came through measured decisions that were small enough to reverse and useful enough to teach us something.

Carrying complexity on behalf of the customer

Web data products have an unusual experience-design challenge: the simplest-looking customer request may be the most difficult one for the platform to fulfil.

High-value targets frequently have sophisticated protections and their behaviour changes over time. ZenRows needed dedicated paths for those environments, but the customer should not have to understand the machinery behind them. The interface and the supporting services therefore had to be designed as one experience, with the system carrying the variability rather than handing it back as configuration and operational work.

That principle guided the rebuild. Complexity inside the platform was worthwhile when it made the customer's path clearer. Customers should be able to focus on the data they need and what they want to do with it, without coordinating all the layers required to retrieve it.

Much of the best infrastructure work here is quiet. Customers experience it as confidence: a demanding task becomes repeatable, the next step remains understandable and the product behaves like one system even when several services are involved.

Bringing ZenRows into AI-assisted development

Alongside the activation work, I explored how ZenRows should meet a development workflow increasingly shaped by AI assistants.

Developers were already working inside AI-assisted environments, so adding an isolated AI-labelled feature would have missed the point. I wanted to bring ZenRows into that context without weakening its access controls or asking customers to work around them with copied credentials and manual requests.

I built a secure MCP connection for Cursor using server-managed authentication. This allowed an authorised development assistant to work with the platform through a controlled path, while keeping access explicit and revocable. Convenience and security were treated as the same design problem rather than opposing concerns.

I also established reusable context layers across the codebases I worked in. Project conventions, constraints and recurring knowledge could travel with the work instead of being reconstructed in every session. The decision reflected a broader view of AI-assisted engineering: useful agents depend as much on clear context and boundaries as they do on model capability.

Together, these pieces created a credible route for AI-assisted workflows, built around durable access and shared understanding rather than a one-off demonstration.

The outcome

Over six months, ZenRows moved from a fragmented view of activation to a shared measurement system spanning the customer journey. A broader application experience—combining rebuilt journeys with trusted parts of the existing product—was introduced through controlled weekly learning rather than a single high-risk release. The platform also gained a secure path into AI-assisted development workflows.

Product, engineering, growth and data could now work around the same question: how quickly and confidently can a customer move from intent to useful web data?

What stayed with me is that activation cannot be reduced to one screen, one tour or one conversion event. It is the quality of the path between a customer's problem and the moment the product becomes a dependable part of solving it. Improving that path meant bringing measurement, product judgement, technical execution and rollout discipline together.