Gladia is a deeptech startup building one of the most performant speech-to-text APIs on the market, competing with players like Deepgram, AssemblyAI and Speechmatics. When I joined, I was the first and only designer on the product. No PM, a small engineering team wired for backend performance, and a webapp that had almost no structure.

My title was Founding Product Designer. My actual role was closer to Designer + PM: framing scope, writing specs, aligning stakeholders, handling QA, and driving delivery alongside engineering. All of it, from day one.

I was brought in to redesign the webapp. But within the first few weeks, I realized the webapp wasn't the first problem. The first problem was that nobody could experience Gladia without signing up.

There was no way to see the product, test the API, or understand what it actually did without going through a full registration flow. The value was invisible. Marketing was sending traffic to a wall.

I expanded the scope on my own initiative and proposed a lightweight mini app, a discovery layer between marketing and the product, before touching a single screen inside the webapp. That decision shaped everything that followed.

The mini app was designed around one constraint: two clicks, no signup, immediate value. A user landing on the Gladia homepage could test the API in real conditions, with Live Transcription or Speech-to-Text, before ever seeing a registration screen.

I owned the UX, information architecture and interaction model end-to-end, including animation concepts to make the experience immediately legible. Visual identity was handled externally.

The goal wasn't to build a marketing page. It was to create a concrete, functional representation of what the API does, something that qualified leads instead of just capturing them.

With the funnel open, I could focus on what happened after signup. The webapp had limited functionality, no structured evaluation flow, and no architectural foundation to support the depth of the API. It wasn't a redesign problem. It was a platform problem.

I defined a product vision around six principles: fast to value, progressive depth, predictability, technical clarity, scalability, and reliability. Every decision that followed came back to those.

In practice, that meant rebuilding the transcription experience from the ground up. The previous interface showed raw text, nothing else. I introduced clear state management, live statuses, developer-oriented views with JSON output and code samples, and a modular layout separating input, output, logs and metadata. Users could finally see how the engine worked. That built trust, and trust shortened the path to value. Advanced settings followed the same logic: easy things stay easy, complex things become explorable. The API had depth. The platform now exposed it.

On the infrastructure side, I rebuilt usage and billing entirely, shifting from post-consumption invoicing to a credit-first system with top-up flows, auto-refill and low balance alerts. Small change in principle, significant change in how developers trusted the product day-to-day.

Gladiator was an internal benchmarking tool built by developers for developers. It worked technically, but the interface was too raw to show to clients. Sales couldn't use it, and results were hard to interpret without deep technical knowledge.

I redesigned it as a client-facing asset: a clear visual grammar for model names and performance indicators, readable benchmark results, a layout that preserves scientific depth while making outcomes immediately comparable. Sales could now run live comparisons with client data and present them in a conversation without friction.

Working without a PM taught me to hold the full scope, but the absence of a second brain to challenge decisions is something I'd never underestimate again. The real friction wasn't design: it was alignment, with founders moving fast and an engineering team wired for backend depth rather than front-end clarity.

One thing I would have pushed harder on: a richer user layer, analytics, admin, account intelligence. I raised it early, mapped the next moves ahead of time specifically to avoid being blocked later. But it didn't get traction. The focus stayed deeptech-only, with no clear product priority beyond the core API, which eventually led to a full stop on that direction. The tension was real: what the technology could do and what users and customers actually needed to experience it weren't moving at the same speed.

The biggest shift was learning to design in a market where your product is one API call away from being replaced. That changes how you think. You stop optimizing screens and start thinking several moves ahead, betting on depth, on trust, on the kind of experience a developer actually wants to come back to.