Around 2012, one of our customers at Radvision was a US prison system. They used our software to schedule 15-minute video calls to inmate cells. Missed slots, wrong routing, dropped calls, every failure carried human weight.

The customer had zero professional developers. The scheduling logic had to be written by their staff. That constraint was the single most important thing to design around, and the choice we made about the SDK is the one I still think about.

The Customer That Made Everything Real

At Radvision I was one of the engineers on a cloud call-routing platform. The product controlled incoming calls for organizations that needed serious routing logic: call centers, banks, and a US prison system. The prison was the customer that made the design decisions concrete, because they had the strictest constraints and the weakest engineering bench.

Inmates were scheduled for 15-minute video call windows. The system had to route the right call to the right cell at the right time, handle no-shows and rescheduling, and never drop a live conversation halfway through. The rules were their rules, not ours. They needed to encode facility-specific scheduling policies we would never know in advance.

Which meant the SDK, the way we let customers program our system, was not a documentation exercise. It was the product.

Why the SDK Was the Whole Product

Radvision’s CTO had deep expertise in real-time communications and limited exposure to modern cloud tooling. Our team’s job was to bridge that gap without turning every customer engagement into a six-week onboarding project.

If shipping the product meant every customer needed a professional engineer on staff, we would lose the market. Call centers, banks, and prison systems do not staff up on Python developers to configure their routing.

The SDK had to be usable by the same person who would otherwise be manually filling in a scheduling spreadsheet. That constraint made every other design decision downstream.

Picking JavaScript on Purpose

The instinct in 2012 for an SDK was to give customers a Python or Java library, a package manager, some sample code, and a getting-started guide. We tried that framing on paper and threw it out.

Every step in that flow was a step where a non-technical customer would stop.

  • Install a runtime. Not going to happen on a prison IT department’s timeline.
  • Configure a package manager. One more thing to fail, one more thing to support.
  • Read a getting-started guide. Support-ticket generator.
  • Set up a local environment. Every customer is running a different OS, different Python version, different network policy.

 

The JavaScript-in-a-browser bet skipped all of it. Open the URL, you are already in the SDK. There is no install to get wrong. The runtime is the browser they already have.

What “Browser IDE” Meant in 2012

The interface was a full authoring surface inside a browser tab. A few things had to work together for that to feel like a real tool rather than a toy:

  • CodeMirror as the editor. Syntax highlighting, autocomplete, error underlines. Made the browser feel like the IDE the customer never installed.
  • A sandbox for testing. Customer could write a routing algorithm and simulate an incoming call against it, right there in the browser, without touching a live line. This alone eliminated most of the “what happens if” support questions.
  • Publish in place. When the algorithm was ready, one button pushed it live. No CI pipeline, no deploy script, no ticket to open. Same tab, one click.
  • Versioning built in. Every publish kept the previous version reachable, so a customer who broke something could roll back without calling support.

 

The whole design collapsed the distance between “I have an idea for how this should work” and “the system is now behaving that way.” The friction points that would have made the SDK too hard for a non-developer were removed one by one, until the SDK was just: a page, a text editor, a test button, a publish button.

What the Prison Team Actually Did

The prison staff who ended up using the tool were not programmers. They were operations people who understood their facility’s scheduling constraints better than anyone else could. Once the authoring surface was in front of them, they wrote their own scheduling logic, tested it against their own call patterns, and shipped it. Without a training session.

The interface was the training.

Support tickets stayed low. The engagements that would have required a professional services team to babysit ran themselves. That was the outcome that mattered. Not a benchmark, not a metric, but the fact that the customer did the work.

The Timeless Lesson: Meet Them Where They Are

The choice we made was not about JavaScript being a better language than Python. It was about picking the interface with the shortest distance to the customer’s existing comfort level.

The customer already had a browser. They did not have a Python environment. They did not have a build system. They did not have a CI pipeline. Every element of the SDK we did not require was an element that could not go wrong for them.

The engineering flex was not the sophistication of the tool. It was how invisible we could make the tool. The thing they had to learn was the domain logic, which they already knew. Not our stack.

The 2026 Version

The same call shows up now, in a different costume.

Teams building AI products in 2026 have to make an equivalent decision. Whoever is going to program your system, meet them at their comfort level, not yours. Two flavors of that call I see teams get wrong:

  • Building a config DSL when the users can barely edit YAML. The 2026 version of “here is our Python SDK.” Same shape, same failure. If your customer is not going to learn your DSL, the DSL is not shipping.
  • Building a prompt-only surface when the users need structure. The opposite failure. Some users do not want to freeform-write their way to a working configuration. They want templates, guardrails, and a preview. Meeting them where they are can mean less flexibility, not more.

 

The winning move, either way, is the same as in 2012. Design the authoring surface at the customer’s comfort level, not at yours. The engineering pride belongs to how few things they had to learn.

Let’s Talk

If your team is building a product that customers or internal operators need to program, and the current authoring surface is producing more onboarding calls than shipped configurations, that is usually a “meet them where they are” problem. Happy to walk through what your version of “browser tab, one button, one click” looks like. Reach out.