Kite

Challenge

AI builders like Bolt and Lovable were changing expectations for how quickly people could create software. Appsmith had strong backend infrastructure for internal tools, but its existing low-code product was not designed around AI-first creation. The initial challenge was to turn Appsmith’s technical strengths into an AI-first experience that could move users from vague intent to a useful, editable product. As the market became more crowded, the challenge sharpened: we needed to find a focused audience and a use case where our product had a clear reason to exist.

Solution

I led research and design for an AI-first creation flow that guided users from an initial prompt through conversation, generation, and editing. The product began as an agentic frontend builder for enterprise internal tools, then evolved into an AI website builder for solopreneurs. Throughout that pivot, the core interaction model stayed consistent: help users express and refine what they need, show what the agent intends to do, and give them a clear way to shape the result.

Testing the market while designing the product

The market was evolving weekly, so discovery could not be a one-off phase. I set up two parallel work streams: a continuous research loop to track user expectations and competitor patterns, and a design track to make the first product direction tangible enough to test and build. I led the direction across both work streams, while sharing execution with a fellow product designer.

Each week, we asked users in our target audience to build internal tools using emerging AI builder platforms. As the audience shifted, the research shifted with it. As new tools appeared or existing tools evolved, we tested those too.

In parallel, I mapped the first creation flow in Figma around the core loop that would shape the product throughout: prompt, conversation, generation, and editing. The goal was not visual fidelity; it was to make the product direction concrete enough for leadership and engineering to critique, test, and build from.

Making the agent legible to the user

Research showed that users struggled to trust AI builders when the agent’s interpretation of their request was either hidden or buried in long conversational explanations. They often skipped those explanations, but still wanted a clear preview of what the system intended to build before committing to generation.

That led to a design hypothesis: users needed visibility at two key moments: before execution, to review and approve the agent’s plan; and during execution, to understand what the agent was doing in real time.

Early exploration: readiness and PRD preview

I first explored this through two connected patterns: a readiness indicator that showed whether the agent had enough context to start building, and a live PRD preview that surfaced what was already happening in the background. Engineering had architected the system to translate the user conversation into a PRD, which then informed the app-generation agent. My idea was to expose that intermediate artifact to users, so they could see how their request was being interpreted before generation began.

But both patterns had issues. The readiness indicator created more ambiguity than clarity. “Ready” was hard to define, fragile to measure reliably, and did not answer the user’s real question: how long until I can see a result? If we blocked users from generating early, they became frustrated. If we let them proceed, the score lost meaning.

The persistent PRD created a different mismatch. Engineering could generate it as an intermediate artifact, but maintaining it reliably throughout the full editing lifecycle added complexity and cost without enough return. I wanted to avoid surfacing an important contextual artifact only to remove it later.

We opted to cut both patterns, but kept the core insight: users needed visibility into the agent’s intent before execution, and its progress during execution. That became the basis for two lighter patterns: the plan and agent status.

Pattern 1: A lightweight plan inside the conversation

I evolved the PRD concept into a lighter inline chat component we called a plan. Instead of maintaining a full requirements document, the agent summarized its next steps directly in the conversation, where users could review, edit, and approve them before execution.

The plan made the agent feel more predictable. Users could see what would happen next, adjust the direction before execution, and avoid waiting for a result based on the wrong assumptions.

Pattern 2: Agent status as a system state, not a chat element

Once a plan was approved, users needed to understand what the agent was doing during generation.

My first version placed agent status near the input field, following a pattern we had seen in Cursor. It showed the current step, but testing showed that the placement overloaded the composer. Users were not always sure whether they should type, wait, or interact with the status.

I moved status to the top of the chat and gave it a stronger visual treatment. This made it read as a system state rather than a chat element. I also refined the plan visually, so users could better understand upcoming steps and how each item related to progress.

Together, plan and status created a lighter interaction model: first the agent made its intent reviewable, then it made its progress visible. This gave users more control without relying on a heavyweight PRD artifact.

Refining the product into a full IDE

With voice set aside, we kept refining the editing and product experience. Each iteration pushed it closer to a complete tool: not just a generator, but somewhere users could shape and maintain what the agent built.

Over time it became, in effect, a fully fledged IDE for AI-assisted tool building. It was fully functional, with data integration, styling, and version control, plus inline components that surfaced development-centric detail directly in the interface, down to editing the generated code in context.

That progress exposed the real problem. We had built something close to what the competition already offered. Our one clear differentiator was the Appsmith backend, and that advantage was eroding as competitors stood up their own enterprise-grade backend services.

The product was strong, but it no longer had a reason to exist that only we could claim. We needed to pivot.

Refocusing on a clearer audience

Leadership made a radical pivot: narrow the focus to solopreneurs. These were non-technical people starting one-person businesses who needed to launch a brand, website, and online presence quickly. Existing website builders were too broad and manual for this audience, while ecommerce platforms’ AI features were still too immature to offer a truly guided creation experience.

This provided us with a real window of opportunity. The challenge became to take what we had, reshape it around this audience, and ship in less than three months.

Rebuilding the flow for non-technical users

To get Kite launch-ready for the new audience, we needed to validate the product with solopreneurs and complete the editing experience. I created a new research plan and test script so we could evaluate the current flow against this audience instead of relying on assumptions from our earlier developer-focused work.

Testing showed that solopreneurs struggled with the blank prompt. They were less interested in describing a technical product and more focused on explaining their business, their offer, and the kind of identity they wanted to create. In response, we stripped out much of the technical dialogue and made the onboarding more guided.

The initial prompt view used rotating examples to help users get started. During the conversation, we combined open dialogue with lightweight questionnaires to help users describe their business, offer, and desired identity.

Instead of moving straight from conversation to website generation, Kite first showed users a set of visual directions to choose from. My first version used style cards with fonts, color swatches, and imagery, but testing showed that this was too abstract. Users did not want to imagine the result; they wanted to see what their website might actually look like.

Generating multiple full websites would have taken too long, so I worked with engineering on a lighter preview step. They introduced a dedicated model in the agentic stack focused on generating quick visual previews within minutes. Once users could choose from realistic website directions instead of abstract style cards, the response was much stronger.

Editing made simple

While my co-designer focused on the website launch flow, I focused on editing. At that point, users could refine the generated site through chat or edit the code directly. For solopreneurs, code editing was irrelevant, and chat-only editing created a targeting problem: users often knew what they wanted to change, but struggled to describe where it was.

I designed an edit mode where users could select an element directly on the page and then make changes in context. Editing combined inline controls for simple adjustments with agent instructions for broader changes. The goal was to let users point first and instruct second, instead of forcing them to describe the target from memory.

I ran into two constraints. First, bespoke inline controls for every element type were too expensive to build within the launch timeline. Second, user testing showed that selecting an element and then moving back to the chat broke context. Users expected something to appear where they had clicked, not in a separate panel.

I simplified the concept into a more flexible edit mode. Users could select a component directly on the page, which opened an inline prompt input in context. Instead of relying on custom controls for every element, the interface gave users a clear target and a natural place to describe the change.

This was also where mobile came in. We had not explored the mobile experience yet, and editing was where it mattered most: a solopreneur is as likely to refine their site from a phone as from a laptop. I took ownership of the mobile edit UX.

The hard constraint was space. On a phone you cannot place a full canvas and a chat thread side by side the way you can on desktop. I designed the mobile edit mode to keep both in view at once: the page stays visible and directly selectable while the conversation and inline prompt stay within reach, instead of forcing users to switch between a preview and a chat screen.

Launch

Kite launched publicly in February as an AI website builder for solopreneurs. The final product had moved far from the original internal-tool concept, but several design principles survived the pivots: guide users from vague intent to concrete output, make the agent’s intent visible, show progress during generation, and keep the result editable.

The strongest through-line was an interaction model for making AI creation feel understandable and controllable: explain what the agent intends to do, show what it is doing, and give users a way to shape the result.