All work

Strivelabs · Design engineer · 2024 → now

Strive AI

A marketing chat that answers in live interfaces, not paragraphs, and today the way customers get almost everything done in Strive. This is my side of the story.

Role
Design engineer · frontend
Team
5–6 engineers · CTO + I built the foundation, the team built on it
Status
In production, still shipping
Link
strivelabs.ai

At a glance

The problem

We wanted one way to get things done in Strive, and chat was becoming the front door to work in the AI era. So we set out to power the whole platform through chat.

My part

  • Research and the bet. Learnt how the frontier labs, like Anthropic and OpenAI, approach generative UI, and weighed potential ready-to-use fits such as the Vercel AI SDK and Thesys. Then made the case for owning the base.
  • The chat, with our CTO. The two of us built it from the ground up: UI contracts, progressive streaming, retries and failures, and chat UX designed in code.
  • Foundations first. The design system, component registry and AI elements, with Storybook and documented contracts, were in place before any wiring.
  • Slot types. On our CTO’s slot foundation, I designed the slot types and shared one agent UI between chat and the standalone app.

Our CTO owned the backend, infra and the idea of slots. The wider team added to the base as it grew.

Shipped

In production with customers. It’s the core of Strive today: almost everything happens through chat.

What are we working on, Mariappan? Report Builder Performance dashboard Weekly ads recap Wasted spend breakdown Channel comparison

How I work

Build it so everyone can build

  • Design in code. I designed the chat UX straight in code, and built every component standalone in Storybook, so each one is easy to build and test on its own.
  • Docs as context, for people and agents. As the team’s core frontend engineer, I set up the foundations so everyone could build interfaces with AI coding agents. The docs are their context, so I’ve kept them up to date with every version since.

Foundations

Bones before features

  • Defined primitives, AI elements, screens and layouts before features piled on.
  • Those layers became the base of our block concept: everything the model renders is built from them.

The bet

Own the chat, don't rent it

  • Streaming and AI elements: build it ourselves, or pull in a ready-made kit?
  • I bet on owning it. Chat is the core, and flexible interfaces are our moat.
The price: every bug is ours. Worth it for the one surface everything else runs through.

There’s a lot more behind this call: what we tried, what we weighed, and why. The full story is in the blog

Design call · slots & canvas

Move the canvas out of the thread

  • Answers can be rich surfaces: artifacts, an editor, whole pre-built agent interfaces.
  • We first rendered them inline. It worked, but it kept hurting my taste, so I redesigned slots to open in a right-hand panel.
Same slot, two homes. Inline, a rich surface fights the thread for space. Beside it, both get the whole screen.

AI elements registry

The pieces our use cases asked for

  • @strivelabs/ui-core for the foundations, @strivelabs/ui-blocks for reusable blocks, with our AI elements across both.
  • Most AI kits don’t ship with these. I thought a few less common pieces would suit marketers well, so I pitched them to the team as experiments, and designed and built the ones that stuck. Five I’d pin:
  • Overflowing tabs Many series, one strip. Scroll it, never wrap it.
  • Charts with markers Dots, lines, areas, or all three. Show what changed, when.
  • Editable list Grouped rows the agent drafts and you tweak before Apply.
  • Stacked suggestions Next prompts, fanned like a deck, not a wall of chips.
  • AI section editor Select a section, say what to change, get an edit back.

Under the UI

A parser and a contract for everything

  • Custom streaming parser between backend blocks and the renderer. Inspired by langdiff, extended with our platform specifics.
  • One contract system for interactive, read-only and stateful components alike. Hard to get right, and it took a lot of client and server pairing.

Misses & lessons

What I'd tell day-zero me

  • MissRendered rich slots inline, in the thread.

    LessonGive big surfaces their own room. The container should fit the content, not the other way round.

  • MissAsked the model for one giant JSON per answer.

    LessonMake complexity additive. One bad block should never sink the whole reply.

  • MissWorried a side panel would look like a copy.

    LessonFamiliar is a feature. Stand out on what goes inside the pattern.

  • MissNo AI playbook on the team, me included.

    LessonBenchmark, borrow, break, repeat. Ship small and learn in production.

Deep dive · ~15 min read From answers to UI: how we built Strive’s generative UI engine The options we weighed, why we took the bet, and everything that broke along the way. Read the full story

Back to all work