AI Agents Platform

We started by building the wrong thing

When our team pivoted to Lindy, the plan was to build the ultimate AI personal assistant: one thing that could manage your calendar, write your emails, and handle the busywork through conversation. It demoed well. It also wasn’t what people actually wanted.

The problem showed up the moment real users touched it. AI that worked as a black box made them nervous: the demos were slick, but the first time an assistant did something unexpected, the trust was gone. And underneath that, people kept reaching for something we hadn’t built. They didn’t want our assistant. They wanted to build their own. A sales team wanted an agent that qualified leads. A support team wanted one that triaged tickets. A recruiter wanted one that screened candidates. No single assistant was ever going to cover all of that.

So the thing we actually needed to design wasn’t an assistant. It was the platform that let anyone build one.

Fridays with new users

The reason we caught this early is almost embarrassingly simple: every Friday, we sat and watched new people use Lindy for the first time. Not curated power users, just whoever had signed up that week, going through onboarding cold.

Those sessions did more than surface usability bugs. They’re where we heard “this is great, but can I make it do X?” enough times to realize that “X” was the actual product. As the founding designer I owned the whole surface (research, interaction, visual design, the design system), but the Friday ritual was the part that kept me honest. It’s hard to keep believing your own assumptions while you watch a stranger get stuck on them, week after week.

That left me with a harder design problem: how do you let someone who can’t code build an AI agent without making them feel like they’re programming?

Designing for “build your own”

A few decisions came out of that.

The first was to never start anyone from a blank canvas. New users picked a pre-built template (customer support, lead qualification, data enrichment) and edited it. You could build from scratch if you wanted, but you didn’t have to, and most people learned the system by taking apart something that already ran.

I also wanted an agent’s logic to be something you could actually see. Instead of burying behavior inside a prompt, every step an agent took (drafting an email, updating a sheet, calling an API) became a node in a visual flowchart you could read, rearrange, and try out in a sandbox before it went anywhere near real data. Leaning on a familiar shape was deliberate: a flowchart isn’t a new idea, and that was the point. People already know how to read one.

And the biggest one was trust, which turned out to be most of the work. For anything with real consequences (sending an email, writing to a database), the agent stopped and waited for a person to approve the action before it ran. It’s a small thing to describe and it changed everything: it was what made people comfortable pointing Lindy at actual work, and what unlocked the business use cases that needed a human in the loop.

Shipping every week

None of this came out of a long design sprint. The loop was deliberately short. I’d design something, we’d ship it, and we’d watch people react, often inside the same week. If a few people tripped over the same thing on Friday, it was usually fixed by the next one. We instrumented the product enough to tell which stumbles were real patterns and which were one-offs.

Working this way meant shipping things that weren’t finished, which took some getting used to. The trade was worth it: we almost never burned a month polishing something that turned out to be the wrong idea.

Moving between agents in the finished platform

How it turned out

The platform bet paid off. Lindy did around $15M in revenue in its first year. But the number I cared about more was quieter: people who built one agent usually came back and built another. Someone would automate lead qualification, watch it work, and a week later they’d have built something else entirely, and often walked a coworker through doing the same. That second agent was the real signal we’d gotten it right.

The onboarding work compounded, too. Between the templates and the steady Friday-driven fixes, the time it took a new user to get their first agent running dropped from about 45 minutes to under 15.

What I learned

I started this project certain we were building a personal assistant, and our users gently told me, every Friday, that they wanted something else. Pivoting meant throwing away work I was attached to, but the product only found traction once we followed what people were actually trying to do instead of the vision we’d walked in with.

Staying close to first-time users was the habit that made that possible. It’s easy to design for power users once you know a product intimately; the Friday sessions forced me to keep feeling what it was like to encounter Lindy cold, week after week, and that kept us honest about complexity.

And with AI specifically, I learned to ship in order to learn. People use these products in ways you can’t predict from a design file. The fastest way to find out what actually works is to put something real in front of them and watch what they do with it.