John Spooner

Case Study

Session Builder: Cutting time-to-value in complex technical trials

I built a visual JavaScript builder that stopped API implementation work becoming a bottleneck during technical trials, helping prospects get meaningful proofs of concept running faster.

  • Technical Sales
  • Technical Build
Featured Demo

Session Builder

The preserved interactive Session Builder. Configure options and watch the generated JavaScript update in real time.

This preserved demo was built for desktop and is best viewed on a larger screen.

Open in new tab

Surfly enterprise trials lasted for two weeks. The person responsible for getting the initial proof of concept running was often technically capable, but not necessarily a frontend engineer or someone already familiar with Surfly's API.

The problem was rarely understanding what they wanted Surfly to do. The problem was getting enough JavaScript in place to actually test it.

The version embedded here preserves the original configuration and JavaScript-building interface. Live Surfly integrations, widget-key validation and session-launch functionality have been removed because the original environment is no longer available.

During technical trials, prospects regularly reached the point where they understood the use case but got stuck translating it into Surfly's JavaScript API.

A realistic implementation could involve combinations of session settings, arrays, selectors, metadata, tags and event handlers. None of those were necessarily difficult in isolation, but getting them all into a working frontend snippet took time.

That created a recurring sequence:

  1. The prospect decided what behaviour they wanted to test.
  2. They reached the JavaScript implementation.
  3. They got stuck on configuration, syntax or event handling.
  4. I either stepped in to write or debug it with them, or the POC stopped progressing while they worked through it themselves.

In a two-week evaluation, that was a real sales bottleneck. Time that should have been spent testing whether Surfly solved the customer's problem was instead being spent fiddling with implementation code.

A sales process should not stall because a prospect is fiddling with JavaScript before they can test the thing they actually came to evaluate.

When a prospect got blocked, there were two bad outcomes.

The first was that I had to dedicate Solutions Engineering time to routine implementation work: finding the relevant configuration, assembling the snippet, debugging syntax and getting the trial moving again.

The second was worse: nobody intervened immediately and the evaluation lost momentum.

A short technical trial should be measuring whether the product can solve the use case. It should not be measuring how quickly the prospect can learn an unfamiliar JavaScript API.

There was also a scaling problem. The more trials we ran, the less sense it made for the same implementation patterns to require direct support from me or another technical team member every time.

Most of the code causing this friction was not unique.

Across different prospects, the implementation repeatedly involved the same types of work:

  • overriding session settings
  • selecting server regions
  • defining elements to mask
  • adding custom tags and metadata
  • opening additional tabs
  • wiring common behaviours to session events

The customer's desired configuration changed, but the underlying JavaScript patterns were highly repeatable.

If the implementation pattern was repeatable, the code generation could be repeatable too.

Instead of maintaining a library of snippets or writing variations manually, I could put those implementation patterns behind a visual interface and generate the correct code from the customer's selections.

I built Session Builder: a customer-facing interface that translated configuration choices into Surfly JavaScript in real time.

I built the original tool before generative AI coding assistants were part of my workflow, writing the interface and JavaScript logic directly.

The builder made common implementation tasks configurable through the UI:

  • Session settings: toggles exposed the many Surfly settings that could be overridden through the JavaScript API.
  • Server selection: users could select regions and the builder generated the corresponding array.
  • Element masking: selectors entered through the interface were assembled into the required masking string.
  • Tags and metadata: users could construct values without manually formatting the corresponding JavaScript structures.
  • Additional tabs: extra URLs could be configured through the interface and added to the generated implementation.
  • Live code generation: the JavaScript pane updated as the configuration changed.

The original version could also initialise against a customer's Surfly environment using their widget key and pre-populate the interface from their existing global settings. That meant the user started from the way their account was already configured rather than reconstructing it manually.

I also built several event-driven patterns into the interface so common trial requirements did not need to be written from scratch.

These included:

  • transferring host and control when an agent joined
  • automatically starting traditional screen sharing
  • switching video into full-screen mode
  • ending a session if no agent joined within a defined period
  • ending inactive sessions after a timeout

Selecting one of these options generated the corresponding event-handler logic in the JavaScript preview.

Session Builder turned a recurring Solutions Engineering dependency into a self-service starting point.

The original workflow was straightforward.

  1. Start from the existing environment.
    The user entered their widget key. Session Builder used the live Surfly API to read the account's global configuration and pre-populate the relevant settings.

  2. Configure the POC visually.
    The user selected settings, regions, masking rules, tags, metadata and common behaviours through the interface.

  3. Generate the implementation in real time.
    Every selection updated the JavaScript shown alongside the controls. Arrays, strings, configuration values and event-handler blocks were assembled automatically.

  4. Use the resulting code.
    The original tool could run the snippet immediately, copy the generated JavaScript, or copy a version containing an example custom HTML button.

The code pane was deliberately visible throughout the process. The tool was not trying to hide the API. It gave prospects a quicker way to reach a valid implementation while still showing them exactly what was being generated.

Where a setting or concept required more explanation, I linked directly to the official Surfly developer documentation. Session Builder accelerated the repetitive implementation work without trying to replace the canonical technical reference.

The portfolio version is intentionally reduced.

It preserves:

  • the original configuration interface
  • the JavaScript-generation logic
  • the live code preview
  • the local settings, arrays, selectors, tags, metadata and event options
  • the ability to copy generated code

It no longer performs:

  • live Surfly initialisation
  • widget-key validation
  • importing global settings from a Surfly environment
  • launching real co-browsing sessions

Those functions depended on the original Surfly environment and have been removed from the preserved version rather than left partially functional.

Session Builder remained in use for years.

Prospects were directed to it when they needed to get an initial proof of concept running, particularly when the person responsible for implementation was technically capable but did not work with frontend JavaScript every day.

Instead of starting from a blank editor, they could configure the behaviour visually, inspect the generated implementation and use that code as the starting point for their own integration.

Our technical teams used it for the same reason. During trials and live demonstrations, assembling a bespoke configuration through Session Builder was often faster than writing the equivalent JavaScript manually or searching through a library of previous snippets.

That helped in two ways:

  • prospects could keep making progress without waiting for dedicated Solutions Engineering support for every routine configuration question
  • my time could stay focused on the parts of the evaluation that genuinely required bespoke technical judgement

Customers who used Session Builder during evaluation subsequently accounted for approximately €45k in closed MRR. That revenue cannot be attributed to one tool, but its repeated use across successful evaluations demonstrated that it addressed a genuine source of friction in the technical sales process.

The goal was not to remove technical involvement from the sale. It was to stop repeatable implementation work consuming the time needed for the parts that were actually bespoke.