Lexful is an AI knowledge ops platform built for Managed Service Providers. I joined as founding design partner in September 2025 with a clear brief: take the product from zero to one in five months. No design team, no existing foundation, no room for false starts.

Outcomes

We forecasted 30 founding circle members at launch. That filled almost immediately, so we expanded to 100. Even then, more than 120 additional members were still in the pipeline waiting to join. Eight design partners committed before the product was finished. Five months from zero to launched.

The Challenge

The MSP documentation space is well-established but underserved by modern tooling. The opportunity was to build something genuinely AI-native -- not a legacy tool with AI bolted on, but a product designed from the ground up around how AI can make documentation faster, smarter, and more useful for the people doing the work.

The design challenge was twofold: move fast enough to validate assumptions with real customers, and build a foundation robust enough to scale when those assumptions proved out.

My Role

As founding design partner, I owned the full scope of product design -- from sitting with customers and synthesizing what they told us, to building functional prototypes to test our hypotheses, to defining the interaction model, to building the design system the engineering team would build against.

There was no design team. Every decision mattered and nothing could be precious.

The Process

Listening First

We started with customers before we built anything. I led a series of design partner interviews to understand how MSPs were currently handling documentation, where the pain was, and what they actually needed versus what they said they needed. Those conversations shaped everything that came after.

Rather than manually synthesising hours of customer meetings, we used AI to identify patterns across conversations quickly. This let us move from customer insight to product decision in days rather than weeks, and meant we could run more conversations without losing fidelity.

An AI-First Way of Working

AI wasn't just in the product; it was in how we built the product. We used it to synthesize meeting notes and surface recurring themes across customer conversations. When we had a hypothesis to test, whether it was a specific interaction pattern or a broader assumption about how MSPs wanted to work, I'd build a working prototype using Figma Make or Claude Code and connect it to a Supabase backend. That gave design partners something they could actually use, not just look at, with real data flowing through it.

We'd run four or five design partners through each prototype, gathering feedback in real time as they interacted with it. We synthesized that feedback and fed it directly back into the product. The loop from hypothesis to working prototype to validated decision often ran in days, which is what a five-month runway demands.

This wasn't AI-assisted mockup work. We built functional, data-backed prototypes as our primary way to test product decisions, then acted on what we learned.

Building the Design System

One of my first substantive decisions at Lexful was to build a proper design system before building the product. In a founding context, the instinct is always to ship first and clean up later. I've seen what that costs, and I made a different call.

The conventional wisdom is to defer the system until the team is big enough to feel the pain. By then the product is too far along to fix without stopping everything, the system gets deferred indefinitely, and every new feature compounds the debt.

My read on Lexful was different. Eight design partners before launch, a founding circle that blew past its initial target almost immediately. That's not a slow-burn product -- it's something that could scale fast. Scaling fast without a system underneath it is how you end up with inconsistent decisions across a product that customers are paying for.

Building the system first wasn't the cautious choice. It was the aggressive one.

The system was built in two layers. The Brand collection defined the primitives: full colour scales for every hue (50 through 950, in both light and dark mode), typography families, font weights, and spacing values. These are the raw materials -- values with no opinion about where they get used.

The Alias collection mapped those primitives to semantic names that reflected intent, not value. Text/Primary, Text/Disabled, Primary/Button/Default, Primary/Button/Hover, and so on. Each token resolves to a specific Brand token in both light and dark mode, so a single design decision cascades correctly across both themes without manual intervention.

Crucially, the semantic naming was structured to mirror the ShadCN component library the engineering team was building against. That alignment wasn't cosmetic. It meant the design system and the component library were speaking the same language, and a decision made in Figma translated directly into an engineering decision without negotiation or interpretation.

The component layer built on top of that foundation. Every component was built with conditional logic around states, sizes, and variants, fully expressed in the token system. The button family alone covers seven variants, three sizes, and five interactive states, all resolving through the token chain in both light and dark mode.

Why this matters beyond efficiency

A design system built this way has a third audience beyond designers and engineers: AI-assisted design and engineering tools. When a component is named Primary/Button/Hover and resolves through a documented chain to Colour/blue/600, that chain of intent is legible to any tool that needs to reason about the system -- not just reference it. At Lexful, that was a deliberate architectural decision. We were building an AI knowledge ops platform, and we built the system to match.

The practical result: when engineering needed a new component or pattern, the design decision was already made and documented. No back and forth, no inconsistency, no debt. And as the product scaled, the system scaled with it.

Reflection

What this project reinforced for me is that design's highest leverage in a founding context is not the screens. It's the decisions you make about how to listen to customers, how to translate what you hear into product direction, and how to build systems that let a small team move at a pace that would otherwise be impossible. The screens matter too, but they're downstream of everything else.

Building AI-first isn't about adding AI features. It's about designing a product and a process where AI is embedded in how value gets created: for the customer and for the team building it.