BLUF
I joined an early AI app builder made by engineers. I helped turn it into Pave, a public product with a clear builder experience, version control, planning mode, direct editing and a new navigation system.
- Starting point: a working technical alpha with no clear product system, entry path or shared state language.
- What I did: research, product structure, coded prototypes, recovery, planning, editing, workflow exploration and engineering handoff.
- What reached the product: Pave launched publicly, and Plan Mode, Direct Edit and email notifications are publicly documented. Navigation Phase 1 was an internal release. I do not have a public adoption or retention number.
Quick paths:
The job
- Role Founding product designer for Pave's first seven months; Interim Design Manager and full-time IC
- Timeline December 2025 - today
- Product evolution Vibe UI -> Flint -> Blinq -> Pave
- Public launch Quickbase announced Pave on April 28, 2026 · Pave is live
- Milestones Internal product preview on April 14, 2026 / Navigation Phase 1 released internally on July 16, 2026
- Scope Product design, early research, coded prototypes, interaction models, design QA, rebrand work, motion detail and engineering handoff
For Pave's first seven months, I was the only product designer leading the work. As the team grew, I also took on design-management responsibilities while acting as Pave's lead product designer. Pave grew while many of its rules were still being made. There was no neat enterprise process or clear path from research to wireframes to handoff. I was researching, making screens, writing code and helping define the product at the same time, sometimes across several features in one day. A typical startup vibe.
From working alpha to an actual product
I joined an engineer-built alpha that could turn a prompt into software using Quickbase's backend. The main loop worked: chat sent a request, the LLM generated the code and an iframe showed the result. The rest of the product was still unclear. Back then, Vibe UI had screens, but no clear entry point, navigation, role model, build states or recovery behavior.
Matthew Schweers was the engineering brain behind all of this (shoutout). Ryan Murray led the product direction. I was the first designer on the product, later joined by Johnny Lee, who led the visual and brand direction.
One workspace for chat, building and preview
As the product became Blinq, the sidebar, chat and app preview still did not feel like one builder.
I moved the main design work from Figma Make into a more robust repository on GitHub. I did not want to pay the same extra token costs in Claude, and I wanted more freedom, robustness and power in the prototypes.
Back to the building experience: we wanted more of the building process to happen inside chat. We even imagined all of it happening there, at least in theory. That made it useful to keep chat beside the builder after the first app appeared. The preview stayed as the visual anchor and the feedback loop for the conversation: ask for something, see the app change, correct it and repeat.
The sidebar could expand and collapse, which gave people more building space and less noise when they needed to focus. Chat and the builder used resizable columns. Their boundaries and the top bar stayed fixed, so dragging the split or changing modes did not make the whole app jump around. Themes were a big deal then, so we gave them more space instead of hiding them in settings. 2026 update: enterprise customers still ask for them often.
The top bar became a product-status area. Preview, Publish, Refresh and Live App had to stay clear without getting in the way of building. You can judge how well that worked in the navigation rework. It really did not.
I also tested three role-based home views internally. That gave us a clear observation: a builder, an admin and an end user had different jobs. Giving them the same interface because they shared a login or homepage did not work.
That first role model was incomplete, but it gave us something real to improve.
Component preview for engineers to refer to
A spinner could show that Pave was busy. It could not show what was happening, whether progress was real or when a person could safely step in.
The build experience needed a few clear signals:
- The request was understood.
- Work had started and had steps.
- The generated app was changing in the preview.
- The person could take control again when execution finished.
I explored top-bar status, inline build steps, message queues and SubagentBubble components. Active work expanded. Completed work collapsed. The preview kept every signal tied to the app.
The environment had reusable components, design tokens, dark mode, accessibility checks, motion rules and handoff notes based on states. I started to confuse the size of the repository with how easy it was for the team to use. Direct Edit exposed that gap.
Sense of safety when building
Version history and reverting were already in the alpha. They were becoming common in AI builders, and enterprise users reasonably expected them.
I explored two ways to go back. The first stayed inside chat and tied recovery to the prompt that created each version. The second used a timeline where people could browse old versions, preview one in the builder and then revert to it. Together, these gave people two ways to find the same powerful feature.
People needed to see which version they were choosing and what would disappear. The conversation dimmed every message after that version. The builder preview showed the older app in place.
“Go back” sounds harmless until the interface shows how much work “back” contains.
The alpha supported history and reverting. These interactions were early explorations. They did not make it into the product because priorities changed and versioning is hard to build well. I know that from working on Quickbase's core CI/CD and ALM systems.
The prototypes made one rule clear: show the effect before asking somebody to commit.
Give email notifications an actual editor
Notifications had to carry real weight in Pave, especially since we were building for enterprise teams with complex apps. Even then, we knew a subject line and a textarea would not be enough. People needed to control what triggered a message, who received it, which app data appeared in it and who could edit it.
Back then, this was probably the coolest feature I worked on in Pave. I had room to build a real editor and, in just one day, I made a text editor prototype with Markdown, slash commands, schema-aware variables and a Build with AI mode. The message stayed visible while users managed the audience, triggers, schedule, permissions and rules on the right.
The scope grew because the problem was large. Record events and recurring schedules could both run. Changing the source table reset the recipients, trigger fields and conditions linked to it. Conditions became a nested AND/OR tree. The prototype covered light and dark themes, keyboard behavior, reduced motion and 84 end-to-end checks. For a design prototype, it was robust as hell.
We did not have the capacity to move all of that into production while other launch work was moving. The richer editor, variables, nested conditions and deeper scheduling were cut. Basic email notifications reached Pave. Most of the authoring system went to scrap.
I still think that work could have become a stronger product, but we did not ship enough of it to prove that. What I can show is what I delivered. The released editor itself saw almost no adoption. Most notifications are created through chat, so credit to Pave's agents for making that path work.
Rebrand the system without breaking launch
By the time Blinq became Pave, the product had already been Vibe UI and Flint. Four names in a few months sounds funny until every name leaves colors, type, logos and one-off decisions behind. The builder, navigation, notifications and landing work were all moving toward launch, so there was no clean time to stop and repaint everything.
Johnny owned the palette, icon direction and wider visual language. My part was making that direction work across the real product: light and dark themes, focus and disabled states, warnings, errors, navigation and the generated app inside the builder.
I asked Nick Vanselow for a component analysis before planning the migration. He found Button used in 76 files and 257 Lucide icon uses across 80 icons. I used those numbers to build the Brand Impact Matrix and plan the rollout.
The credit matters. I framed the question and rollout. Nick did the measurement. “I discovered 76 files” sounds better in a portfolio. Nick discovered 76 files.
Plan before spending credits
Plan Mode had become common across GenAI platforms, so we needed one too. When I started designing it, I wanted it to work differently. We expected enterprise users to plan a task and then edit the plan itself to get the best result.
I designed Plan Mode around four steps: clarify the request, show the planned work in a sliding panel, let the user edit the Markdown plan and ask for approval before running it. A labeled Plan/Build segmented control replaced icon-only modes. I built ClarifyCard to gather missing details. PlanCard carried the plan from creation through review and execution. Approve & Run made the result clear.
The PlanCard had eight states: generating, ready, generating steps, draft, executing, paused, completed and cancelled. The number only helped if copy, motion, actions and progress stayed in sync. A paused plan should not shimmer as if it is still working.
Direct edit: introducing granular change
Once Pave could plan and generate, the next problem was clear. Prompting worked well for large changes, but it was clumsy for one exact edit. The first version of Direct Edit was very technical and engineering-led. Joey Cruz allowed users to edit some CSS values directly, but it was not friendly to use.
Make this heading smaller should leave the table below it alone.
I reviewed more than twelve AI builders and design tools. They kept using the same generic CSS controls for buttons, tables and charts. That felt insufficient. It was flexible in the way a box of loose screws is flexible.
I made the selected element the unit of direct editing. Text got text controls. Charts got chart controls and templates. Forms, filters, detail views, badges and metrics got smaller sets of controls that matched their job.
This reduced the need for people to know in advance how an edit should work. Not everyone is a designer, and even designers can struggle with the right control. A prompt or template could give them a useful starting point.
The next decision was to stage each change. Selecting an element created a clean state. Editing created a dirty state. Save and Discard stayed visible until the person saved or cancelled the change. AI-generated software already asks people to trust a black box. An immediate and irreversible local edit would have added another problem.
Johnny completed a visual and UI polish pass for Direct Edit and turned it into something beautiful. I added the interaction timing, component-aware toolbar, motion catalogue and animated icon behavior.
Design and Prompt shared one surface but had different controls. Save and Discard appeared only when there was a real change to resolve. Reduced motion lived in the working prototype so engineering could test it.
During handoff, one of our principal engineers called the Direct Edit handoff the clearest and easiest-to-navigate deliverable. Almost all of the specifications made it into the release. Engineers stopped hunting through my filing system. That mattered more than the code-versus-Figma argument. It was living proof that design could make a positive engineering impact.
Explore how a workflow might become inspectable
While launch and Direct Edit were moving, we explored what might happen if Pave coordinated work across several systems instead of making one app at a time.
The flow moved through three representations: conversation, workflow definition, generated application. Chat remained the authoring surface. I kept the diagram deliberately short of a full visual-programming canvas. It used a staged mental model: here is what will run, in what order, against which connected systems.
The interaction asked clarifying questions, converted the answers into steps, exposed required connections and allowed revision before a dry run and generation. If the workflow depended on Snowflake and Slack, those dependencies appeared in the definition because “we will sort auth out later” is how demos become archaeological sites.
Two designers tested an earlier flow. Three routes silently locked after connection errors.
The happy path had made the diagram reassuring. The broken path revealed that it was also a promise. If the interface showed a staged workflow, it had to explain which step failed, whether earlier work remained valid and whether retrying would duplicate anything.
The workflow concept remained prototype/WIP and unavailable publicly. Later, Johnny Lee developed a much better version, but the early exploration belongs here because it tested how far the product model might stretch.
Rebuild navigation around the product Pave had become
The first Blinq navigation shipped internally. Pave grew past it soon after.
Recent apps on Home could open a live app while the side navigation sent people to the builder. Content design flagged that “Builder” sounded like internal Quickbase language. Pave now included building, app use, permissions, data, publishing and governance. The shell still treated all of that like one long list.
It looked like sidebar cleanup at first. In practice, each new part of Pave needed a clear place to live.
Before shaping the redesign, I asked Kevin Rau for completion, drop-off, time-to-screen, search, support and enterprise-area usage data. Most of it was available in theory. The baseline numbers never arrived in the thread. The redesign used documented friction, Ryan's journey maps and the real permission model instead of a quantitative funnel. I am not adding a research chart to cover that gap.
Over three days, I turned five roles - Builder, End User, Admin, Realm Admin and Viewer - into task flows and storyboarded click sequences.
The main routing question was simple:
- Is the question about the application's content? Stay in Build and use chat.
- Is it about access, data flows, releases or operation? Go to Manage.
Any task that did not fit showed a problem in the information architecture.
That led to a unified top bar, a Build/Manage control and a role-based Manage rail. Simona Georgieva found a problem in the first version: a new builder who went into permissions or version checks might never return to chat. We kept Manage behind first publish and protected Pave's one reliable wow moment.
The label fight was the design fight
Emma Townsend and Eva Miranda proposed Chat | Settings. That was reasonable. Chat is where people build, and Settings is familiar.
I argued for Build | Manage. Settings sounded like minor preferences, but this side of Pave already held data, users, permissions, versions and billing. Workflow ideas also pointed toward more operational work. Chat is a tool. Settings is a destination. Build and Manage are two actions on the same app.
The internal release used Build/Manage. The meeting that settled it is not in the written record. I can show the reasoning and the result, but I will not invent the final speech.
Other decisions followed the same pattern:
- Manage stayed unavailable until first publish.
- Published apps kept the canvas. Pave moved to a low-priority footer chip.
- End users saw “your apps,” not “your projects,” because access was granted per app.
- Theme switching stayed reachable after Ryan supplied the number that changed the IA: one in five users changed their theme.
- Publish versus Share ended in an agreed A/B test.
Ryan signed off on the direction. Kevin made the redesign P0, an Approved branch was cut for engineering and QA continued through release.
The internal Phase 1 release included the unified header, Build/Manage control, grouped header actions, overlay navigation flyout and a less cluttered sidebar.
Phase 1 did not include the Command Center, role-based Manage rail or the wider administration and governance plane. Johnny led design QA for a separate visual refresh of the same sidebar, and Swapnil Mittal planned its implementation.
My favorite unshipped artifact was the Command Center. I would cut it. It repeated the overview cards and needed a grand name to justify the repeat.
The navigation work is a useful ending because it includes the problems that came before it. Build and Manage only make sense after the builder, versions, planning and editing exist. The concept work also tested what the product might need next. The final shell caught up with what Pave had become.
What changed
The original chat-and-iframe demo became Pave, a revenue-generating product, in seven months. I know that part from inside the product. The work covered planning, recovery, local editing, onboarding, an app gallery and a navigation model built around Build and Manage. Each chapter marks whether the work became public, shipped internally, or stayed as a prototype.
Quickbase's launch announcement confirms Pave's public release. Its public materials document version rollback and email notifications, plus Plan Mode and Direct Edit. Navigation Phase 1 was an internal release.
Data around public adoption, retention and task success is still sensitive, so I would share it later. One thing is clear: a small team shipped something huge and complex in a short time.
Related work
Building Pave covers the branch previews, token enforcement and handoff grammar behind this work.
Design systems that AI can use covers machine-readable components, guardrails and human review.