Laurier St-Aubin← All work

Case study · SEDA · 2025–26

SEDA Fast

Getting a SEDA Fast API key used to mean a Telegram message and a wait. I designed the dashboard that handed customers the keys.

Role
Head of Product. Research, scope, UX, UI
Timeline
Nov 2025 – Sep 2026
Worked with
Engineering lead, CEO, full-stack engineers
Status
MVP built. Full hub designed, not built
Sign in to Fast: email, wallet, Google or GitHub, protected by Privy, beside a particle globe

The problem

Customers had no control over their own keys. If one leaked or needed replacing, they couldn't act on it. They had to message us and wait. Every request also pulled someone from engineering or sales off their work.

Before

  1. Ask in the Telegram group
  2. Wait for engineering or sales
  3. Receive the key in chat
  4. Need to revoke it? Ask again, and wait

With the dashboard

  1. Sign in
  2. Create a key
  3. See every key in one place
  4. Revoke it yourself, right away

Research

The core features came from the people who'd use it, and from tools they already knew.

Customer interviewsConversations with customers big and small about how they get, use and manage keys.
Similar toolsA review of how other API platforms handle keys, usage and access.

A system to build on

I'd first built SEDA's design system for the explorer revamp. For the SEDA Fast dashboard, I revamped it again, for a more professional, less crypto-alien look that customers would trust with their keys.

Components from the revamped SEDA Fast design system: buttons, badges, toasts, cards, forms, dialogs, radio cards, charts and the keys table
Components from the revamped system: buttons, toasts, forms, dialogs, charts and the keys table the dashboard is built from.

Read the design system case study →

The MVP

The project was green-lit, and we built the smallest version that solved the problem: create, view and revoke keys, with one login per customer.

Built

  • Sign in
  • Create keys
  • View all keys
  • Revoke keys

Later

  • Team logins
  • Key detail and usage
  • Metrics hub
API Keys page: active, idle, credits and rotation stats above a table of keys with status, created date, calls and last used
Keys. Every key, its status and its usage, in one place.
Create a new API key dialog with name, scopes, rate and spend limits, auto-expire and IP allowlist
Create. Name, scopes and limits. The key is shown once.

The full vision

Beyond the MVP, I designed the full scope: a hub where customers could track their own metrics, with larger products living in the same app. This part was shaped by research on similar tools rather than interviews.

Metrics hubMarket OpsIssuer ConsoleLaunch DeskRisk Explorer
ConceptDashboard home concept: system status, requests, credits remaining, error rate, active keys, request volume and plan usage
Home. System health, usage and plan at a glance, with Create API Key always one click away.
ConceptUsage page concept: requests, credits, error rate, credit consumption chart, plan projection, usage by key and reliability
Usage. Credits, requests and reliability, with a plan projection that warns before you run out.
ConceptSettings page concept: organization, slug, default environment, timezone and a danger zone
Settings. Org defaults, security, webhooks and an audit log.

Where it landed

The MVP was built. I left SEDA in October 2026, before the hub went into development, so there are no usage numbers to share. What's here is the thinking, the research and the design.

Looking back

I'd have built it sooner. Giving customers control of their own keys makes them feel reassured and in control, and I believe it would have helped retention.

Many of the features we planned would also have been useful to our own team internally.