AI Architecture Diagrams: How I Built Codelit Solo

I could describe a system faster than I could draw it. That frustration became Codelit: start with the intent, produce a draft, then give people the controls to question and improve it.

The drawing was only the beginning. The real product was the editing loop.

The first version of Codelit was a text input, a button, and GPT-3.5 on the backend. You'd type "design a URL shortener" and it would spit out Mermaid syntax. I'd render that Mermaid into an SVG and call it a day.

The output was brittle: invalid syntax, unresolved references, and diagrams that looked plausible while describing the wrong thing. Repairing the model's output became a larger job than rendering it.

But people got it immediately. I showed three engineer friends and all of them said some version of "wait, can it do [thing I'm working on]?" That was enough interest to justify another iteration, not proof of product-market fit.

Codelit needed an editor, not only a diagram renderer. Mermaid can attach interactions to SVG output, but dragging nodes and editing their properties called for a different model. React Flow let the graph participate in the same component system as the rest of the app.

I actually tried the raw canvas route for a weekend before writing it off. Drawing boxes is easy. Everything after drawing boxes is the entire product.

The real pivot was parsing AI output into React Flow's node and edge format instead of Mermaid syntax. I wrote a parser that takes the AI's structured JSON response and converts it into { id, type, position, data } nodes and { source, target, animated } edges. That was harder than it sounds, because the model has no idea about pixel positions, which is how I ended up building a layout engine on top of the interactive canvas.

Codelit runs on Next.js with the App Router, Zustand, React Flow, and Firebase. Every one of those choices was made under the same constraint: I'm a solo developer, so anything that costs me a week of setup has to earn that week back almost immediately.

Next.js (App Router). Server-rendered marketing and content pages keep meaningful HTML available without waiting for the editor. Client components handle the interactive workspace, while route handlers cover server-side work. One framework keeps those boundaries close without pretending they are the same execution environment.

Zustand over Redux. Codelit runs on a handful of stores: canvas state, AI generation state, user preferences, template data, undo/redo history, and UI panels. Redux would mean a slice each with actions, reducers, selectors, and a wall of boilerplate. Zustand is create((set) => ({...})) and you're done. For a solo dev, the reduced cognitive overhead is massive.

// This is literally how simple a Zustand store is
const useCanvasStore = create<CanvasState>((set, get) => ({
  nodes: [],
  edges: [],
  addNode: (node) => set({ nodes: [...get().nodes, node] }),
  updateNodePosition: (id, position) =>
    set({
      nodes: get().nodes.map((n) => (n.id === id ? { ...n, position } : n)),
    }),
}));

React Flow (@xyflow/react). It removed the editor plumbing I did not want to own. Layout, validation, and a useful interaction model were still my responsibility.

Firebase. Auth and database in one SDK. I didn't want to run a Postgres instance, set up migrations, manage connection pools, or deal with auth middleware. Firebase Auth handles Google and GitHub sign-in. Firestore stores diagrams as documents. It's not the cheapest at scale, but for a product finding market fit, speed of iteration beats cost optimization.

Codelit didn't start as an architecture tool. The original idea was a coding education platform: interactive coding exercises with AI hints. I built about 30% of that before realizing the architecture diagram feature I'd hacked together as a "bonus feature" was getting more usage than the actual coding exercises.

I killed the education platform and went all-in on architecture generation. This was scary because I'd spent two months on the education features. But the data was obvious: people were sharing the diagrams, not the coding exercises.

Three problems kept pulling me back into the product: plausible but wrong AI output, a layout engine that took six rewrites, and pricing copied from a tool with a different usage pattern. Each needed a product decision, not just another prompt.

The AI output wasn't "needs minor tweaking" bad. It was "suggests putting a load balancer behind the database" bad. Fixing it meant sitting down with hundreds of generated diagrams, tagging what was wrong, and tuning the system prompts against that. The generation pipeline that came out of it is a post of its own.

The layout work taught me to separate topology from geometry. The current architecture canvas uses graph depth and type-based fallback rows; the user can then adjust the result. The important boundary is that a model does not need to invent pixel coordinates.

Pricing was the one that stung, because it was the one I could have reasoned my way out of. I launched at $19/month because I looked at what Lucidchart charges. But Codelit isn't Lucidchart. It's a tool engineers reach for on specific tasks, not all day every day. $19 felt expensive for something you use a few times a month. I dropped to $12, then eventually settled at $5/month with a 7-day trial, and conversions jumped. The dated growth retrospective, is separate.

Agent workflows made the same editing problem more consequential. A diagram can be wrong without changing a system; a tool call can write to one. I wanted the plan, permissions, and evidence to remain visible when the workflow moved from design toward execution.

A workflow needs more than a list of agents. It needs a defined input, tool boundaries, model choices, approval points, and an explicit account of what happens when a step fails. Provider routing is one part of that, not a substitute for the rest.

A dry run helps you inspect a workflow's intended sequence without treating the simulation as a completed job. It can expose missing inputs and awkward approval points. It cannot prove that a provider is connected, that an action is permitted, or that a real result reached its destination.

That distinction shapes the product:

Approval gates and budgets matter, but no label should imply that an agent cannot fail or incur unexpected costs. The useful result is a bounded run with evidence you can inspect.

Codelit now starts with a Thread and the question, "What should we make real?" Product Plan, Architecture, Agent Teams, and Browser are workspace apps around that conversation. The design goal is to keep the task in one place while making each tool's role explicit.

The architecture work is still there: editable diagrams, the template library, failure simulations, and rough cost estimates. A simulation is not a production incident test, and an estimate is not a cloud quote.

As of September 2026, the plans are Free, $5/month Pro, and $15/month Team. Hosted model and browser usage have their own allowances and availability requirements. The pricing page is the place to check current limits.

The through-line is unchanged: turn intent into something you can inspect, make the next decision visible, and keep the difference between a plan and a completed action honest.

Three things: start with the canvas instead of Mermaid, charge from day one instead of running a free beta, and start writing content in month one rather than month three. The common lesson is to put the core editing and feedback loops in front of people sooner.

Start with the canvas, not Mermaid. The Mermaid detour cost me three weeks. I should've gone straight to React Flow.

Write content earlier. Useful architecture walkthroughs can demonstrate the product while teaching something on their own. I would begin that work alongside the prototype, then measure whether readers actually activate.

Open Codelit with one real task in mind. Inspect the plan, change a decision, and see whether the next step gets clearer. That is the test I want the product to pass.

If you are building something similar, I am happy to compare notes. The most useful conversations are usually about the part that still does not work.