Past work · By

Translucid: how the infrastructure became Qube

Visit Translucid.cloud ↗

Seven months of engineering, more than thirty customer conversations, and a change in what I was asking people to adopt.

Why I started with assessments · The work behind a responsive session · Every use case asked for a different environment · What thirty-plus conversations changed · Giving the technology a product of its own · What those months were worth

Why I started with assessments

Real-time AI tools made me question the assumptions behind online assessments. An assistant could interpret a screen or listen to a conversation from outside the application being monitored. Restricting what happened inside a browser tab could only address part of that problem.

I wanted to move the sensitive workspace into an environment the platform could control. The participant would still interact through a browser, but the actual browser, terminal, or assessment software would run in an isolated cloud session.

Translucid was my attempt to make that capability available to other companies. An assessment platform could keep its interface and content, then embed our protected workspace underneath it.

The work behind a responsive session

I spent roughly seven months working through cloud isolation, browser media security, and the lifecycle of remote sessions. Keyboard and mouse input had to reach the cloud machine, and the result had to come back quickly enough for someone to type, navigate, and work comfortably.

An ordinary remote desktop did not address the whole problem I was interested in. I explored DRM and browser Content Decryption Modules to protect the returned media on supported devices. That brought encryption, session keys, playback behavior, and operating-system differences into the same system.

A working demonstration was only one part of the job. Sessions needed to start reliably, survive interruptions, and shut down cleanly. A small delay that seemed acceptable while watching video could feel frustrating while editing code.

The difficult work often happened between those pieces. A healthy network connection did not necessarily mean smooth playback. A session could be running while the user could not yet interact with it. I had to learn to judge the experience from the person using it, as well as from the services underneath.

Every use case asked for a different environment

The original idea expanded from a protected browser into custom workspaces. A programming interview might need an IDE. A practical certification could need particular command-line tools, software versions, or a configured environment.

These were plausible uses for the same foundation, but each came with another set of decisions: persistence, network restrictions, authentication, recording, and integration with an existing product.

I kept seeing possibilities across universities, recruiting platforms, certification providers, and sensitive remote work. It became harder to decide which experience we should make reliable first. Supporting the infrastructure was starting to look like supporting several different products.

What thirty-plus conversations changed

I spoke with more than thirty potential customers and people working around assessments and recruiting. I wanted to understand whether Translucid fit into the products they already had.

Those conversations made the cost of adoption much clearer. Someone considering infrastructure has to think beyond whether the demo works. If they build a critical workflow around it, they inherit its reliability, compatibility, and support risks.

As a small, unfamiliar company, we had to earn that trust while still proving there was a business. That was difficult. Engineering progress did not automatically make an integration easier for another team to justify.

I had started with friends, and some stepped away as the work continued. They did not see the same path forward, and I could not point to enough customer evidence to remove the uncertainty. I kept working, but I was asking myself many of the same questions.

Giving the technology a product of its own

I eventually decided to build an experience on top of the infrastructure myself. A meeting room was specific enough to explain and useful enough to try without first integrating a new platform into someone else’s application.

That became Qube: video, audio, and a shared cloud computer for sensitive demos and collaboration. The protected-session work stayed valuable, but the entry point changed. Someone could join a room and understand what it did.

This did not make the engineering simple or solve every security problem. Protection still depends on the device and playback environment. It gave me a clearer product boundary and a direct experience to improve.

Qube website showing secure demos and shared cloud collaboration
Qube grew from the Translucid infrastructure into a meeting experience people can use directly.

What those months were worth

I sometimes wish I had tested the adoption question earlier. I was drawn to the technical challenge, and it was easy to interpret another working component as progress toward a company.

The work was not wasted. Qube depends on things I learned and built through Translucid. But I now separate the value of a technology from the willingness of a particular customer to adopt it.

I still see uses for Translucid as standalone infrastructure. For now, I am concentrating on the meeting experience it made possible, with a more specific answer to who it is for and how they can start using it.

Read about Qube

Back to projects / Research