In this post, I’ll cover how to leverage Claude Code to convert from Figma to code. Specifically, I’ll cover:

• What MCP is and how the Figma MCP server connects to Claude Code

• How to convert a Figma design into a working prototype with one prompt

• Why that basic approach produces code your engineers can’t use

• An advanced approach that produces code engineers can use

Let’s jump in!

What is MCP?

MCP (Model Context Protocol) is a translation layer that lets AI agents talk to other products. Claude Code, Cursor, ChatGPT, Codex, they can all use MCP to reach out to external tools and pull in information or take actions.

The Figma MCP server lets Claude Code read your designs directly from Figma. It pulls in screenshots, design context, exported assets, component information, all of the things Claude needs to understand what your design looks like and how it’s structured.

To get started, you need two things connected:

1) Figma: You need a full Figma seat with dev mode. In your design file, you’ll see an MCP option in the right panel when you enter dev mode. This tells Figma to make the design data available.

We’ll be using this dashboard design as our demo.

2) Claude Code: You need to add the Figma MCP server to Claude Code. You can follow the instructions here to set this up.

The Figma plugin for Claude Code also comes with built-in skills. A skill is a pre-written collection of prompts that tells Claude how to use the Figma data effectively. When you ask Claude to implement a Figma design, it automatically uses a skill called “Figma Implement Design” that Figma themselves wrote.

The Basic Workflow

Let’s walk through the simplest version of this.

I start with an empty folder in Claude Code. I then go to Figma, select the frame I want to implement (in this case, a dashboard design), and copy the example prompt that appears in the MCP panel. It looks something like: “Implement this design from Figma.”

I paste that into Claude Code and hit enter.

What happens next is a series of tool calls. Claude Code reaches out to Figma through the MCP, grabs the design context, downloads a screenshot, exports assets like images and icons, and reads through the component structure. It’s pulling in everything it can to understand the design

After a minute or so, the prototype is done. Comparing the original Figma mock to the implemented code, it’s 90 percent the same. The layout matches, the components look right, the data is in the right places. You’ll likely notice some differences, such as responsive layout gaps in the table or small changes in the components themselves.

From here, you can keep prompting to prototype any new experience you have in mind. Claude Code is not opinionated about your framework, so you can do this with React, Vue, Angular, or any other framework.

Although this is a quick way to generate a prototype, the quality of the code itself is not great. Claude Code had to reinvent every component used (buttons, badges, cards, etc), rather than reusing the components already in your code base. The basic prototype is still useful for showing your team how an interaction should feel, or for validating a concept with stakeholders, but the code doesn’t save your engineers any time.

Getting Better Results

To get a prototype that’s actually useful to your engineers, you need your design system. Set up a second project that contains your real code components (buttons, card, badges, etc). I’m using IBM’s Carbon design system, but at your company it would be whatever your team has built. The components are sitting in the folder, not being used yet, just available.

Now go back to Figma, copy the exact same prompt, paste it into Claude Code. I’d recommend adding ‘build with my existing components’ to ensure Claude Code doesn’t try to invent new components to use.

Visually, the output looks almost identical, but the code is now using our real components. You’ll noticed the difference in the table formatting, the tabs, and the cards.

Here’s a small snippet from the beginning of the code that shows these imports:

import {
  Theme,
  Tabs,
  TabList,
  Tab,
  TabPanels,
  TabPanel,
  Tag,
  Table,
  TableHead,
  TableRow,
  TableHeader,
  TableBody,
  TableCell,
} from '@carbon/react';

In the past, most teams would get 80% of the design complete and accept it as good enough. Now, when we hand off to engineering, they get a prototype that they can easily pick up and implement. This allows PMs and designers to speed up implementation and no longer requires engineering to get small details about the design right.

This is the kind of workflow we go deep on in the AI Prototyping course: how to set up your component library, how to handle design systems that aren’t perfectly documented, and how to iterate until the prototype is production-ready. Over 1000 PMs from companies like Meta, Google, Microsoft, and OpenAI have already enrolled.

Check out the full syllabus here!

Subscribe now

Tool calling is an essential step in building AI agents. It allows the LLM to request information or take an action completely autonomously. There’s only one downside - every time you use a tool, the results load into the context window, taking up space and degrading the quality of future tool use.

This post will walk you through programmatic tool calling, a technique where a model writes code that orchestrates tool calls rather than the calls itself. You’ll understand why it can outperform standard tool calling by up to 20%, how both Anthropic and Cloudflare have shipped production implementations, and when it’s worth the added complexity.

Let’s dive in!

The Problem With Standard Tool Calling

Ai agents all work the same way: the model requests a tool call, your server executes it, the result enters the context window (the model’s working memory for the current task). The model then reasons about what to do next, and the cycle repeats for each step. For any complex task, this often means 50+ tool calls per user request.

For example, let’s say we had an agent for managing our team’s expenses. The goal of the agent is to report back who has exceeded their budget for the month.

The model would start by calling get_team_members(), then calls get_expenses() for each person. It would then calculate each person’s budget one at a time, and finally return the list of people who exceeded the budget. All of this information has to sit in the context window, likely overwhelming the available memory and causing the agent to fail.

All the intermediate data (the list of members and their expenses) the agent stored in its context window was only useful for calculating the end result. This is where programmatic tool calling can help.

Why Code Beats Tool Calls

LLMs are much better at writing code than any other capability, including tool calling. A team at University of Illinois Urbana-Champaign first noticed this in 2024 with their paper CodeAct. Instead of having an agent call tools normally, they gave the agent a Python environment where it could write code. This code would call the tools instead, which means only the final result would enter the context window.

Results across 17 models on standard benchmarks showed up to 20% higher success rates compared to JSON and text-based tool calling, with fewer turns required to complete equivalent tasks.

There are three main reasons why code outperforms regular tool calls:

• Models have deep familiarity with coding from pre-training

• Code has built-in control flow: loops, conditionals, and composition of multiple operations in a single action

• Code can call existing libraries rather than being limited to pre-defined tool schemas

Also, when the generated code fails, the model can read the structured error output from the interpreter and revise the script.

Let’s take another look at our expenses agent using programmatic tool calling. Instead of calling each tool on each employee, our agent would write a script that executes this for us. Remember that the agent is writing the code to use tools, the code runs, and the agent sees the result.

And finally, here’s what our context windows would look like between standard and programmatic tool calling:

The Two Major Implementations

Both Anthropic and Cloudflare shipped production implementations in 2025 and early 2026. They reach the same outcome through different architectural choices.

Anthropic: Programmatic Tool Calling

Anthropic released Programmatic Tool Calling in November 2025. The model writes Python that runs in a managed container. Your tools opt in by specifying allowed_callers: ["code_execution_20250825"] in their definition. The code runs inside the container, calls your tools as needed, and only the script’s output enters Claude’s context when it finishes.

Measured results on complex research tasks:

• 37% average token reduction (43,588 to 27,297 tokens)

• Up to 98% reduction for workflows with large intermediate data (150K tokens to 2K)

• Accuracy improvements on internal knowledge retrieval benchmarks (25.6% to 28.5%)

Anthropic released Programmatic Tool Calling alongside two related features worth knowing. Tool Search lets agents discover tool definitions on demand instead of loading all of them into context upfront (85% token reduction on MCP evaluations). Tool Use Examples lets you attach concrete usage demonstrations to each tool definition, improving accuracy from 72% to 90% on complex parameter handling. These three features together are Anthropic’s approach to scaling tool use without linearly scaling context costs.

One practical note: Anthropic recommends assigning each tool to either direct calling or programmatic calling, not both. The model performs better with unambiguous guidance about how each tool should be called.

Cloudflare: Code Mode

Cloudflare built the same pattern independently, calling it Code Mode. The model writes TypeScript instead of Python, and the code runs in lightweight sandboxed JavaScript environments rather than containers.

When the model decides to act, it writes a function like sendEmail:

async () => {
  const weather = await codemode.getWeather({ location: "London" });
  if (weather.includes("sunny")) {
    await codemode.sendEmail({ to: "team@example.com", subject: "Nice day!" });
  }
};

When to Use It

Programmatic tool calling can make your agent workflow more complex. Because the agent doesn’t see context in between steps, it won’t have any knowledge of what happened during that time. With any highly interactive and contextual use cases, this can make the agent feel slow and forgetful.

Use cases that work better are those that require reading in a lot of information to reach some final conclusion, and do not require the ability to chat with each individual data element. Other good use cases include handling a large number of tools, or restricting what data the model can see.

Let’s try two common agents: a coding agent and a data analysis agent.

With a coding agent, typical tools would include edit_file, read_file, and search. If we use programmatic tool calling, the coding agent would write a python script that would attempt to batch these reading and updating together. This could save on context window usage, but the agent would be required to reread files after every edit, as it would’t see the edit tool call results.

With a data analysis agent, we might have tools like run_query and create_chart. Based on the user’s question, the agent would run one or more queries and produce a visualization. Here programmatic tool calling would save a lot of time and tokens, as the intermediate query results themselves may not be important.

If most results in your workflow are just inputs to the next step and don’t need the model to reason about them directly, you have a strong case for programmatic tool calling.

Programmatic tool calling is not an often discussed topic, so I hope this helps you understand what it is, how it works, and when you should use it!

Subscribe now

Last year, I shared a lot of guidance on using component libraries with AI prototyping tools to improve the quality and consistency of your prototypes.

Today, teams are beginning to move towards using their real code in prototypes instead of AI generated code. What does this mean?

Instead of asking the AI to create a button or chart for you, you import your existing code components to your prototyping tool. This gives you two critical benefits:

1. You know that the prototype will look exactly like your product

2. The code has actual value to the engineering team

The main problem with AI prototyping is that it’s fast to spin up a new idea, but the artifact itself has no real value. The code generated doesn’t use your real colors, components, or systems. So if you give it to an engineer, they basically have to start from scratch.

This new wave of prototyping uses real components so that hand of to engineering has actual value. They can use the prototype as an accurate reference for implementation and even point their coding agent (aka Claude Code) at it to implement directly.

This isn’t theoretical. Based on a small subset of data from a popular AI prototyping tool, only 41% of teams selected Figma as their import source when adding a design system. A combined 36% were code (Github + Storybook), and another 16% were MCP.

In this post, I want to break down nine ways you can use a design system with AI prototyping tools, including MCP, skills, and more.

Let’s dive in.

1. Screenshots

Taking a screenshot of your existing UI and pasting it into an AI tool is the lowest-friction starting point. You screenshot your dashboard, paste it in, and ask your AI to recreate the layout. AI returns a visual approximation typically built with shadcn/ui.

The AI has no knowledge of your actual components, tokens, or design system. The output will use whatever default stack the tool prefers (almost always shadcn/ui plus Tailwind) and you’ll spend more time retrofitting the result to your design system than you saved.

This can be useful if you want to a scrappy idea quickly, not when you need design system accuracy.

Best for: Early exploration when you don’t care about design system fidelity. Communicating a rough layout idea you plan to refine with a real method later.

2. Prompt-only / paste code into chat

You copy-paste your component source code directly into the chat prompt and instruct the AI to use those components. Paste your <Button>, <Card>, and <Input> into AI with: “Here are my components. Build a settings page using only these.”

With this approach, the AI tool needs to read all your components on each prompt, and it likely won’t be able to reconstruct them accurately unless you’re using the exact same tech stack. Even after you provide components, you need to re-prompt explicitly with each specific component, naming what to use and when.

Token limits also cap how many components you can paste. Bolt’s free tier burns through 300K tokens quickly. v0 is “tightly coupled to ShadCN and not flexible in this regard”.

Best for: Nothing really, there are better approaches.

3. npm package + explicit prompting

This was the initial attempt at solving design systems and multiple products shipped support for NPM packages (Figma Make, Bolt, Lovable, etc).

You publish your code to npm, a package registry that allows you to easily install it in other environments. Then you jump into your favorite prototyping tool and tell AI tools to install and use it.

The problem is that all AI prototyping tools have strong defaults and just don’t know how to use your components. In my experience, this led to more errors and headaches than using a screenshot.

Some of this pain can be alleviated with good instructions, but it almost always still falls short.

Best for: Teams with an already-published library who want a low-effort foundation. Pairs best with context files that document component usage patterns.

4. Bolt Design System Agents / Magic Patterns design systems

These are platform-native features that ingest your component library and constrain code generation to your design system. Bolt’s Design System Agents (launched March 26, 2026) let you upload component source files, a Storybook URL, or brand guidelines. The agent “learns” your system and uses your components in subsequent builds.

I gave this a try and the results were not great. Here’s a quick side by side of the Figma mock I had (using a design system) and the Bolt design using a matching Storybook.

Magic Patterns is another tool focused on design systems. You can import a structured set of rules, typography, colors, and reusable components that apply automatically to every generated prototype. Teams create components by importing from Figma or with screenshots, reference them by name in prompts (@LibraryName/Button), and publish versioned updates that can be bulk-applied across all designs using them.

This approach works well, but can be tedious to import and doesn’t match your existing code. The team has a private beta for importing code components that appears to solve this by allowing bulk imports via Figma and MCP.

Both platforms are React-only, limiting your options if you’re on a different stack.

Best for: Design-focused teams who primarily prototype in one browser tool and need the lowest technical barrier.

5. Storybook MCP

The official @storybook/addon-mcp exposes your Storybook component metadata (names, props, descriptions, stories, screenshots) to any MCP-capable AI tool. You install the addon and add the MCP endpoint to your Claude Code. Claude Code then has tools like list_components, get_component_props, and get_component_source.

This is explicitly marked “highly experimental” by the Storybook team. I haven’t done a ton of testing with this, so I won’t share an opinion for now. From what I’ve seen, it’s mostly useful if you want to automatically create new Stories in Storybook, not for prototyping outside of the tool. Feel free to share if you’ve given this a try!

Best for: Teams already invested in Storybook who want cross-tool component awareness. Treat this as an additive layer on top of context files, not a standalone solution.

6. shadcn-compatible registry

You restructure your components into shadcn’s registry.json format so they install via npx shadcn add @namespace/component. This lets you easily import individual components as needed for prototyping.

The fundamental constraint is again tailwind and react. If you’re already using a compatible stack, this option can be a good place to start, but many teams are not.

Best for: Teams building on or willing to align with Tailwind/shadcn.

7. Custom MCP server

This is a newer pattern and takes a moment to understand.

You build a custom MCP server that exposes your component library’s metadata as structured tools. Tools like list_components, get_component_props, get_component_source give Claude Code or Cursor on-demand access to your components, usage examples, and anti-patterns.

For large component libraries (100+), you should implement pagination or search, as dumping all components at once can exceed the context window on most AI models.

The main downside of MCPs for design systems is the number of queries and tokens your agent will do. You’ll find that Claude Code constantly is reading documentation before doing any prototyping work, slowing down the speed of iteration.

The results are often quite good - here’s another look at the dashboard from earlier:

This also requires some technical skill as MCPs are best used by desktop coding agents like Claude Code or Codex.

Best for: Teams comfortable with a little technical complexity and engineering bandwidth to support internal servers

8. Figma MCP + Code Connect + Claude Code

I don’t have access to Code Connect, so I can’t speak much to this workflow. I’ve seen good results, but I know it also take a lot of time and effort to set up.

Code Connect works by creating a .figma.tsx file per component that maps the Figma component to a React import and includes a usage example. After running npx figma connect publish, the AI receives actual import statements and component mappings.

Without Code Connect configured, you can accomplish something similar by writing a skill in Claude Code that maps your Figma components to code. It won’t be as accurate, but its a good place to start.

Best for: Teams with a well-maintained Figma design system and Code Connect already configured (or willingness to set it up).

9. Components + custom skill + Claude Code

This is my recommended approach if you’re technical enough and focused on engineering handoff.

Your component library lives in the repo directly. You create a SKILL.md that documents what components you have and usage rules. Claude Code reads both the skill and the actual source files, which gives the AI a full understanding of how to use the components.

As an example, here’s the same dashboard comparison with Figma first and Claude Code + components + Figma MCP second:

If you don’t want to working in the main repo, you can export just your components to a dedicated repo for prototyping. You can also pair this with screenshots or imports via Figma MCP to easily spin up interfaces for your ideas.

Best for: Teams that want maximum code & design fidelity between their design system and AI-generated prototypes.

Quick comparison

To wrap up, here’s a quick comparison chart of all the import methods covered in the post:

Where to start

If I had to recommend one thing to start with, it would be getting comfortable with Skills and MCP. Being able to move information between systems with MCP is a critical workflow, and learning how build Skills to document the exact instructions an AI should follow provides a lot of leverage.

Ultimately, the right approach depends on how technical your team is. Use web based tools like Bolt or Magic Patterns if you want a low barrier to entry. Use Claude Code + MCP + Skills for the best possible results.

I hope this breakdown was helpful in seeing all the ways teams are approaching this problem!

Subscribe now

Platforms like N8N, Zapier, and frameworks like LangChain have made it easy to build AI agents without necessarily knowing what’s happening underneath. That works, right up until your agent does something unexpected and you have no idea why.

In this post I will show you exactly how agents work by walking through how to build one step-by-step. We’ll use a customer support agent as the example throughout.

You’ll learn what a tool is, how the LLM and your server pass information back and forth, how the agent decides when it’s done, and how to assemble all of it into a working loop.

Step 1: Get an LLM that supports tool calling

The first thing you need is a large language model (LLM) that supports tool calling. Tool calling is a feature that lets the model request that your server run a specific function, rather than just generating text.

A tool is a function you define and describe to the LLM before the conversation begins. You tell the model: these are the actions available to you. The model then decides, based on the conversation, whether to call one and which one to use

For example, you could build a tool called ‘search_web’ that looks up information online, rather than depending on the LLMs existing knowledge. To use the ‘search_web’ tool, you would:

1. Create an tool handler on your server that can search the web when the ‘search_web’ tool is called

2. Send a request to the LLM with the ‘search_tool’ included in the list of available tools

Tool calling has only become reliably good recently. Models from Anthropic, OpenAI, and Google have improved dramatically over the past two years. That improvement is what made agents practical outside of research settings.

Step 2: Decide when the agent should stop

An agent running in a loop needs an exit condition. Two approaches work well together:

A “done” tool. You define a tool called something like complete_task or end_conversation. When the model calls it, your loop exits cleanly. The agent finishes when it decides it has finished.

A maximum iteration limit. You set a cap on the number of loops. Max iterations are useful as a safety net, but hitting the limit means the agent ran out of turns before it could complete its work. You’ll want to handle that case explicitly so the user knows what happened.

Most production agents use both: the done tool as the primary exit, max iterations as the fallback.

Step 3: Give the agent some tools

The tools you provide define what the agent can actually do. For a customer support agent, three categories make sense:

Information lookup: search the knowledge base, pull up a customer’s order, check account status

Escalation: route the conversation to a live agent when the issue is outside what the LLM can resolve

Actions: issue a refund, update a shipping address, cancel an order (start with read-only tools and expand from there)

Each tool is a function your server exposes. The LLM requests it by name with whatever arguments it needs. Your server runs the function and returns the result.

Each tool has a list of arguments or variables that can be passed in, like the order ID that needs to be refunded. Tools also have a description that helps the agent understand how to use them, and can return errors that tell the LLM what went wrong. These errors can allow the agent to self correct if they’re descriptive enough!

Step 4: Write the system prompt

Before the loop starts, you give the LLM a system prompt: a set of instructions that defines how it should behave. This is where you set the agent’s personality, scope, and guardrails.

For a customer support agent, your system prompt might include:

“You are a support agent for Acme. Always look up the customer’s order before responding. If you cannot resolve the issue with the tools available, escalate to a human. Do not guess at policies you don’t know.”

The system prompt is the single biggest lever you have over agent behavior. A well-written prompt prevents most of the edge cases you’d otherwise spend days debugging.

I’ll include full details on writing and improving system prompts in an upcoming post!

Step 5: Put it all in a loop

When a user sends a message, your server calls the LLM with the full conversation history. The model reads everything and decides what to do.

If it decides to use a tool, it responds with a structured message containing the tool name and arguments. Your server runs the tool, collects the result, then calls the LLM again, this time passing the full conversation including the tool request and the result.

The LLM reads all of that context fresh and decides what to do next, usually calling another tool or generating a final response. This continues until the agent calls your done tool, you hit the max iteration limit, or you fill up the context window.

The context window is the maximum amount of text you can send to the LLM in a single call. A 250k token context window works out to roughly 1 million characters of text, which sounds like a lot, but each tool call adds to the history you carry forward on every subsequent call. A long agent session fills the context faster than you’d expect.

There are strategies for managing and reducing the context window, including compaction and removing old tokens from tool calls and thinking — to be covered later!

Putting It All Together

To make this concrete, let’s trace a full example. A user says their order never arrived. The agent looks up the order, finds it’s lost in transit, issues a refund, and tells the user. That’s two tool calls and a final response, all handled without a human.

Remember, a basic agent has five components:

1. An LLM with tool calling support

2. A done tool and a max iteration limit as exit conditions

3. Tools for the actions your agent needs to take

4. A system prompt that defines behavior and constraints

5. A loop: call the LLM, check for tool use, run the tool, call the LLM again

Every agent framework you’ve seen, from LangChain to N8N to Zapier, is an abstraction on top of this loop. Knowing how the underlying loop works is what lets you understand why your agent is behaving the way it is, and fix it when it’s not.

This post breaks down how it works, what makes coding agents different from other AI applications, and what I learned along the way. Let’s dive in!

What Makes an Agent Different

The most common use case for AI applications today is generating text. Whether it’s finding a recipe or helping you write a paper, most people use tools like ChatGPT and Claude as text-based assistants. You send a message, you get a response, and that’s the end of the interaction.

An agent is different. An agent can use tools, maintain state across multiple turns, and work toward a goal that might take many steps to achieve. When you ask an agent to “help me book a vacation” it actually does it, searching flights, reserving hotels, and blocking your calendar. In this model, the valuable part is not the text response, but instead the work done between the user’s request and the agent’s response.

The distinction is important because it changes what you’re building. A chatbot needs good system prompts to present a coherent persona and may need access to external data sources like websites or files. An agent needs good system prompts and a runtime that can execute tools, manage state, handle errors, and verify results. The system prompts are maybe 30% of the work. The other 70% is the harness.

On top of this, coding agents are a degree more complex than regular agents. Where a regular agent may have one way to solve a problem, coding agents have near infinite. Here’s why:

1. Code has to actually run. If you ask an agent to write an email, it can produce something plausible and you’ll judge whether it’s good. If you ask an agent to write code, there’s an objective test: does it execute without errors? This creates a tight feedback loop that other domains don’t have.

2. Code exists in files and files have relationships. Changing one file might break another. The agent needs to understand not just the code it’s writing but the context it’s writing into.

3. Users expect to see results immediately. When you change a UI component, you want to see the updated preview right away. This means the agent needs an execution environment and a real-time preview; you can’t just return text and call it done.

4. Evaluating the quality of coding agents is more challenging. Most coding problems can be correctly solved with many different approaches, so you can’t anticipate all possible correct answers to verify if the agent is behaving properly. Instead, you have to read traces to find common errors and build evaluation sets based solely on the final outcome of the agent.

These constraints shape the overall design and architecture of a coding agent. We’ll take a look at how this works using Chippy as an example.

The Core Loop

Every coding agent follows the same basic pattern.

1. The user sends a message describing what they want.

2. The agent plans the work by breaking it into steps.

3. The agent calls tools to read files, modify code, and interact with the environment.

4. It verifies that the changes work.

5. Then it responds and updates the preview.

Oftentimes there are some visual updates as the agent is working, such as showing tools called or lines of code written. Good UX for demonstrating progress during these long running processes is critical.

Here’s how this was implemented inside of Chippy:

That’s the loop: message, plan, tools, verify, respond. If you understand this pattern, you understand 80% of how coding agents work. It’s surprisingly easy to get a basic coding agent working, but a high quality agent is built in the details.

Chippy’s agent runs on the Anthropic API with a custom runtime. I didn’t use LangChain, the OpenAI Agent SDK, or Anthropic’s Claude Code SDK. I tried these frameworks but I found that they had some core assumptions about the environment they’d be running in that didn’t 100% align to my vision. Additionally, I found using these frameworks abstracted away the core agent loop and made it more difficult to learn how these systems really work.

Building a custom runtime sounds more intimidating than it is. Any LLM provider gives you everything you need: you send messages, the model returns tool calls, you execute them and send back results. The “runtime” is really just a loop. The complexity isn’t in the infrastructure - it’s in the tools themselves and in making the whole system reliable.

Chippy’s agent has about 20 tools. Here are the five that do most of the work:

Let me trace through what happens when you tell the agent “Add a checkout button to the shopping widget.”

First, the agent calls edit_tasks to plan the work:

{

“tasks”: [

{ “label”: “Find the shopping widget component”, “completed”: false },

{ “label”: “Add checkout button with onClick handler”, “completed”: false },

{ “label”: “Wire button to checkout flow”, “completed”: false }

]

}

This does two things: it makes the agent’s thinking visible to the user, and it gives the agent a structure to follow. Without explicit planning, agents tend to jump straight into code changes and miss steps.

Next, it calls get_app_config to understand what exists. The response includes current tool definitions, file contents, mock data, and API connections. The agent now knows the context it’s working in.

Then it calls edit_file to modify the component:

{

“path”: “ShoppingWidget.tsx”,

“instruction”: “Add checkout button below the cart items”,

“edit”: “- </div>\n+ <button onClick={handleCheckout}>Checkout</button>\n+ </div>”

}

In Chippy, Sonnet doesn’t apply the diff directly. Instead, I use a Small Language Model (SLM) to apply diffs. Originally I had Claude using a tool for string replacements, but it would often get white spaces or other small issues wrong that would cause the edit to fail.

The next iteration of edits was to use the File tools offered by Anthropic. I found that these tools conflicted with other beta features such as programmatic tool calling and were difficult for me to iterate on to improve performance.

The final interaction was to have Sonnet generate a text response of what should change and use another model fine tuned to make accurate code changes to apply the change. This handled a lot of edge cases and small issues without using the more expensive Sonnet model and multiple retries.

The practical benefits are significant: lower latency per edit, lower cost since smaller models are cheaper, and fewer mistakes on the actual text manipulation. Claude focuses on the hard part, and the diff model handles the easy part.

Once the edit is finalized, we run through the verification steps. For my agent, that means:

1. Bundle the code

2. Run the verifier skill

Bundling the code is pretty simple. This takes the original code written by the agent and attempts to transform it to what will be displayed on a web browser. If this process fails, the agent gets an error message and modifies the code to reattempt.

The verifier skill is more interesting. In case you’re not familiar, a skill is like a prompt that the agent can choose to load when the user needs it. It allows your agent to ‘download’ new instructions at the right moment in time. A good analogy is like Neo downloading new skills in the Matrix.

My verifier skill is a structured set of checks that runs at the end of each code generation, like a code review that happens automatically before the user sees the result. It’s also context aware, meaning that the instructions loaded will match the set of features currently being used. This helps to avoid situations where the agent incorrectly applies checks for a feature that’s not currently in use.

This approach has caught a lot of errors that would have otherwise shipped to users.

I also use several Anthropic API features that make a meaningful difference, such as prompt caching, interleaved thinking, and memory management.

These features aren’t strictly necessary, but they meaningfully improve reliability and user experience and the integration cost is low.

What I Learned

Here’s my top takeaways after spending the last three months building a coding agent:

1) The Core Loop Is Simple

Building the basic agent loop took about a week. You need three things: a tool for modifying files, an environment to run those files, and a preview to show the user. If you have experience building with the Anthropic or OpenAI APIs, the jump to building an agent is smaller than you might expect.

2) Reliability Is the Real Work

The gap between “works” and “works reliably” is where I spent most of my time. I read through hundreds of execution traces looking for failure patterns. Some problems yielded to better prompts. For example, if the agent kept forgetting to plan first, I could emphasize planning in the system prompt. Other problems required structural solutions like the verifier skill. Giving the agent a way to test its changes and clear error messages was critical to improving reliability.

The honest assessment is that prompt engineering gets you maybe 30% of the way to reliability. The remaining 70% requires building systems around the model: verification, error handling, and careful tool design.

3) Frameworks Encode Assumptions

Every agent framework I evaluated came with assumptions about the environment: local filesystem access, specific conversation structures, particular ways of handling tool results. These assumptions make frameworks easier to use for their intended use case. When your use case differs, you spend more time working around the framework than building your product.

For Chippy, the right choice was building a custom runtime. The Anthropic API is flexible enough that the infrastructure is simple.

In case you’re curious, I worked for about 10 hours a day, six days a week to build Chippy. Here’s roughly how the time broke down:

Weeks 1–2: Core loop implementation, basic tools, first working prototype that could actually modify files and show a preview.

Weeks 3–6: Tool refinement and prompt engineering. This is where I discovered most of the edge cases and failure modes.

Weeks 7–10: Verifier skill development, diff model integration, systematic reliability improvements.

Weeks 11–13: Polish, testing, and launch preparation.

The first prototype came together quickly. Making it production-ready took the remaining 11 weeks.

One more thing worth mentioning: I used Claude Code to write about 90% of the code!

Subscribe now

Li Xia, a product manager turned founder, has developed one of the most systematic approaches to AI-assisted development I’ve seen. Despite starting his coding journey just 2.5 years ago, he’s built and shipped Sondar.ai, an AI-native UX research platform that helps product teams conduct user testing and synthesize insights in minutes rather than hours.

His secret isn’t just using AI tools, but creating a repeatable process that transforms product requirements into working code through a series of structured steps. Let’s dive into how he does it.

Check out the full interview here:

The Product

Sondar.ai addresses a problem Li knew intimately from his eight years in product management: teams struggle with customer discovery. His platform covers the entire research workflow, from planning studies and recruiting participants (accessing 200,000+ participants across 33 countries) to conducting research and using AI to synthesize insights from video recordings.

The platform can test everything from Figma prototypes to live websites, automatically transcribing sessions, extracting key insights, and organizing feedback into actionable categories. What used to take hours of manual analysis now happens in minutes.

The Process

Li’s approach to shipping features follows a methodical five-step process that maximizes AI effectiveness while maintaining quality control.

Step 1: PRD Generation with Chat PRD

Li starts every feature with a comprehensive Product Requirements Document, but he doesn’t write it from scratch. He uses Chat PRD, a tool by Claire Vo, which interviews him about the feature and generates a detailed PRD including business goals, user stories, functional requirements, and user experience flows.

“The PRD step is crucially important because a lot of that detail flows into the design process that follows,” Li explains. This document becomes the foundation for every subsequent step.

Step 2: Visual Design with UX Pilot

Rather than jumping straight to code, Li uses UX Pilot to transform PRD requirements into visual interfaces. He provides the AI with context from the PRD, screenshots of existing UI, and specific instructions about the feature.

The key insight: AI quality dramatically improves with context. Li includes not just feature descriptions but also design principles and system guidelines. “By combining what you are actually trying to build with the principles of your design system, you get much better quality output.”

Step 3: Engineering Task Breakdown

Here’s where Li’s process gets particularly sophisticated. He imports the PRD into Cursor and uses a custom prompt system to generate detailed engineering tasks. His “generate task file” contains specific instructions for breaking down features into parent tasks with detailed subtasks.

The AI creates a comprehensive task list that includes database changes, frontend modifications, and testing requirements. Li reviews this carefully because “once we get into the build process, this is really the blueprint it’s using to turn these prompts into actual code.”

Step 4: Systematic Implementation

Li uses another custom prompt file called “Action Tasks” that instructs the AI to work through the task list one item at a time, asking for review before moving to the next task. This prevents the AI from attempting to build everything at once and failing.

“By having these clear steps, it really helps with that consistency and creates alignment between you and the AI,” he notes. When bugs appear, he can easily restore to a previous checkpoint and retry with different instructions.

Step 5: Iterative Testing and Deployment

Li’s tech stack, Supabase for the backend, Vue 3 for the frontend, and Vercel for deployment, supports rapid iteration. He runs everything locally first, then pushes to staging and production environments as needed.

What Makes This Work

Li’s success comes from treating AI as a team member rather than a magic wand. He’s developed several key practices:

Explicit Instructions: “Sometimes the AI’s quite finicky. Being explicit definitely helps.” Li includes detailed system prompts and repeats critical requirements even when they’re already in his stored prompts.

Reusable Prompt Templates: Li maintains a library of prompt files for different tasks: PRD generation, task breakdown, implementation guidelines. “It’s just a really scalable way to reuse those prompts again and again for every feature that I build.”

One Task at a Time: Rather than asking AI to build entire features, Li breaks everything into discrete, reviewable steps. This makes debugging much easier and prevents cascade failures.

Context Management: Every conversation includes the relevant PRD, task lists, and system prompts. Li ensures the AI always has the full context needed to make good decisions.

What He’d Do Differently

Li’s process has evolved through trial and error. He’s learned that larger features benefit from this systematic approach, while smaller features can be built more casually. He’s also discovered that different AI models excel at different tasks—he’s recently started using Gemini alongside Claude for certain coding tasks.

The most important lesson: investing time upfront in planning and task breakdown prevents much larger debugging efforts later. “Without these detailed steps, the agent will go off in a certain direction, do something, and maybe the output isn’t what you’re expecting.”

Li’s journey from UX designer to technical founder took just 2.5 years, starting with no-code tools like Bubble before transitioning to actual programming. His advice for other product people: Find a project you really want to build and take it one step at a time.

He built productivity tools for his own workflow first, learning database structure and API interactions through Bubble before moving to more complex development. The key was learning incrementally while building real projects rather than following abstract tutorials.

The Results

Li has been shipping features into production for the past 18 months using this process. The systematic approach lets him move from idea to working feature rapidly while maintaining code quality. Most importantly, the process scales—each new feature benefits from the accumulated prompt templates and workflows.

For product managers interested in trying Sondar.ai for their own user research, it’s live at sondar.ai. And for those inspired to build their own AI-assisted development process, Li’s approach shows that success comes not from AI magic, but from treating these tools as powerful team members that need clear instructions and systematic workflows.

Subscribe now

Building prototypes that actually look like your product is one of the biggest challenges PMs face when using AI prototyping tools. In this article, we'll explore three approaches to building a component library that lets you rapidly prototype while maintaining your product's look and feel.

Most AI prototyping tools excel at creating functional interfaces but struggle to match existing design systems. This disconnect means PMs often spend more time tweaking styles than testing ideas. Instead of starting each prototype from scratch, leverage a reusable component library that captures your product's visual language once, then use it repeatedly for all your prototypes.

Let’s dive into the three methods you can use today to build your component library.

Method 1: Screenshots

The simplest approach uses screenshots to train AI tools on your existing UI patterns. While not perfect, it's a quick way to get started without any technical setup.

How it works:

1. Take screenshots of key views in your product

2. Upload them to an AI prototyping tool (like Bolt, V0, or similar)

3. Instead of asking for a complete page recreation, request a component library: "Build a design system that implements the components from this view"

4. The tool will generate individual components (buttons, cards, headers, etc.)

5. Continue prompting to build out additional components

6. Save this as your master project and duplicate it for actual prototyping

Here’s an example result from Google Calendar – not exactly on brand, but better than nothing.

This works best for simple interfaces and will not match the details of your designs exactly, like fonts and spacing. It’s a quick way to get started but most teams eventually want better quality.

Method 2: Chrome Extension Extraction

Chrome extensions offer more precision by extracting actual HTML and CSS from live pages. This method produces higher-fidelity components but consumes more tokens due to larger input sizes. Some tools include React HTML Extension and the Magic Patterns Chrome Extension.

How it works:

1. Install a component extraction extension

2. Navigate to your product

3. Click on UI elements to extract their code

4. Paste the extracted HTML into your AI tool

5. The AI converts raw HTML into clean, reusable components

Pasting in extracted code eats up tokens much faster than screenshots or plain text, so be prepared to spend your monthly allotment just on setting up your component library. Remember that duplicating or forking the library copies all your components automatically, so this is a one time setup expense.

You’ll have better luck on websites that use common styling libraries like tailwindcss. If you have custom CSS classes with external dependencies, don’t expect this method to work that well.

Method 3: Using Production Components

The most sophisticated approach uses your actual production components. This requires engineering support but produces the most accurate prototypes. You’re likely a good fit if your team is using Storybook and is comfortable with Github.

How it works:

1. Create a components-only repository

   • Work with engineering to isolate frontend components

   • Remove all backend dependencies

   • Include only UI components and their styles

2. Import to your prototyping tool

   • Connect your GitHub repo to tools like Bolt

   • Lock all files to prevent accidental modifications

   • Create a duplicate (this breaks the GitHub sync)

3. Build with real components in your duplicate

   • Use your actual component library for prototyping

   • Maintain perfect visual consistency

   • Share prototypes that look production-ready

If your component library is fairly large (50+ files), cloud-based tools may struggle. You may want to use local development tools like Cursor or Claude Code instead. These tools are harder to set up but excel at making changes to larger projects.

The components.md pattern

One unexpected problem is that AI prototyping tools don’t always choose to use your components even if you have them available in the same project. Or, they don’t know how to use your components and frequently cause errors.

I like to solve this with a components.md file. It’s just a text document that describes what each component is, what it’s props are, and how it should be used. This can be generated by AI. When prompting, tell your preferred AI tool to read the components.md file for guidance on interacting with your code. This allows the AI to understand each component without having to read every file.

Choosing the Right Approach

Picking the right approach to components can feel daunting, but you can always upgrade later.

Start with screenshots if:

• You're just beginning with AI prototyping

• Your design system is relatively simple

• You need quick results without engineering support

Use Chrome extensions when:

• You need higher fidelity than screenshots provide

• You're building a one-time component library

• Token costs aren't a primary concern

Graduate to production components when:

• Your team regularly uses AI for prototyping

• You have engineering resources to help

• Perfect visual consistency is critical

Putting It All Together

Building a component library for AI prototyping is an investment that pays dividends. While the initial setup takes time - anywhere from 20 minutes for screenshots to a few hours for production components - you'll save countless hours on future prototypes.

The key is choosing the right approach for your team's maturity level. Most teams naturally progress from screenshots to Chrome extensions to production components as they become more sophisticated with AI prototyping.

Remember: the goal isn't perfection on the first try. Start simple, iterate based on what you learn, and gradually build a library that lets you prototype at the speed of thought while maintaining your product's visual identity. That's how you turn AI prototyping from a neat demo into a core part of your product development process.

Subscribe now

Pat Bergstresser, a product manager at Zillow, approached me with an interesting challenge. Despite having no coding background beyond SQL queries, he'd taken my AI Prototyping course and was now building his second AI-powered product using Replit.

His creation, Vibe Updater, solves a problem every PM knows well: bi-weekly update emails that used to take him 2-3 hours now take just 15 minutes. Let’s dive in to what he built, how it went, and he’d do differently.

The Plan

Pat's approach was straightforward. He wanted to build a voice-to-text tool that also PMs to narrate freeform content and transform them into executive-ready updates.

Target persona: Product managers who regularly send stakeholder updates

Core problem: Writing structured updates takes hours of formatting and editing

Value Prop: A tool that records voice input and automatically formats it into a professional, structured update following a proven template

Differentiation: Pre-built update format that execs love, so you can just narrate and not worry about editing.

Distribution: Currently in early access with just 4-5 PMs testing

The Build

Despite not being a professional engineer, Pat built the entire product solo using Replit:

The technical architecture is simple but effective:

• Voice recording using OpenAI's Whisper API for transcription

• Database integrated directly in Replit (avoiding the complexity of external databases like Supabase)

• System prompts that format content into Pat's proven update structure

• Export options for rich text files, email, or direct copy/paste

Each section follows a specific structure: bold headlines that capture the main point in 30 seconds or less, followed by details for those who want to read more.

How It Went

The product is still in early stages, but the feedback from Pat’s leadership has been remarkably positive. The development process revealed some interesting challenges:

Planning is everything: Pat spends most of his time planning features before implementation. He uses ChatGPT for brainstorming and structuring, then creates detailed prompts for Replit with specific increments.

Incremental development: Rather than asking Replit to build everything at once, Pat breaks features into small increments, testing each one before moving forward. For example, he shipped a feedback feature by:

• First creating the database schema and API endpoints

• Then adding the UI with a feedback button

• Testing thoroughly before adding voice recording capability

Debugging requires patience: When bugs appear, Pat screenshots them and asks Replit to explain before fixing. He's learned to tell Replit to "look at relevant files" to ensure it has proper context before making changes.

What Pat Would Do Differently

Pat's first attempt was a personalized greeting card creator called Card AI. The project became too complex - requiring graphical UI for card designs, integration with printing services, and handling physical mail delivery. He pivoted to Vibe Updater, which better matched his technical capabilities and Replit's strengths.

His key learnings:

1. Voice input changes everything - "When I type, sometimes I limit what I'm gonna say just because I'm trying to get it out quickly. But with voice, I don't overthink it."

2. Replit needs explicit instructions - "You have to be very clear and specific. It really helps you empathize with engineers when you just give them open-ended requests."

3. Manual testing is critical - "You have to test test test and not even just test what you just did but make sure what you just did didn't break something else."

Pat's still considering whether to migrate to Cursor for more robust features, but for now, Replit's integrated database and simpler workflow are meeting his needs. He's already working on the next feature: a "quick update" format for when managers need immediate status reports.

The most striking aspect of Pat's journey is how he's maintained his non-technical identity while building real products. He doesn't fully understand hooks or all the technical details, but he's learned enough about client-server architecture and database concepts to debug effectively and guide the AI tools toward working solutions.

For PMs interested in trying Vibe Updater, it's live at vibeupdater.com. And if you're a PM thinking about building with AI but worried about your technical skills, Pat's story shows what's possible with the right tools and mindset: "It's not like I'm looking at the code files and I can understand them all... but I'm able to actually make some progress."

I hope you enjoy!

Subscribe now

Darren, a product manager from Vancouver, had a simple but persistent problem: missing buzzer calls at his apartment building. Whether it was friends waiting outside or packages being returned, the missed calls were a constant annoyance. Instead of just living with it, he decided to build a solution.

Enter BuzzerBee: Automated Building Access

What it does: BuzzerBee automatically answers buzzer calls and grants building access when you're expecting deliveries or guests. Users can "unlock" their buzzer through the app, and when someone buzzes their unit, the system automatically:

• Answers the call

• Presses the unlock digit (typically 6 or 9)

• Grants building and elevator access

• Notifies you that someone has entered

The Build Journey: From Zero to Revenue in 3 Weeks

Despite being a "non-technical PM" with only basic programming knowledge from his business degree, Darren shipped a working product using AI tools. His iterative approach:

1. Phase 1: Started with just Twilio to test if automatic call answering was possible

2. Phase 2: Built a prototype in Bolt for personal use (got messy, had to restart)

3. Phase 3: Rebuilt in Bolt, then moved to Cursor for the full production app

Timeline: 3 weeks from proof of concept to working product

Current Traction

• Users: 30 active customers

• Revenue: $150/month

• Costs: $50/month to maintain

• Status: Profitable from the start

Key Takeaways for Builders

Start with your own problems: "Figure out something that you can get some users for, use it for yourself, and then start to iterate from there."

Architecture doesn't matter without users: "It doesn't matter if you've got a bulletproof database or the best architecture in the world. If no one uses it, then it doesn't need to scale."

Don't rush into code: Despite the temptation to start coding immediately with AI tools, Darren recommends against jumping straight into development. The iterative, experimental approach proved more valuable.

Subscribe now

I've worked on a lot of side hustles. Since starting university, I don't think there's been a single year where I haven't shipped at least one project. Most of them failed, but I think it's interesting to look back and share some lessons I learned along the way.

In this post, I'll break down the most notable projects and how they went. If you're at all interested in building your own products while working full time, this post is for you.

Walk-In Express - 2017

Total revenue: $0 | Total users: 0

Walk-In Express was my very first real project, built in second year university. It was a web app that allowed patients to hold appointments at walk-in clinics remotely, so they didn't have to show up and sit in the waiting room. This was my first large web application, and the first time I had to really think about incentives for the different types of users involved.

On one side, we had clinics. In Canada, most clinics have more than enough volume that they don't have to worry about getting more patients. My hypothesis was that they would be interested in smoothing out that volume in the day, so that they had a more even distribution of patients. I honestly never really confirmed this.

For patients, the benefits seemed obvious – you don't have to sit and wait. There's a cultural bias towards free services in healthcare here, so it was unlikely I'd be able to charge patients a meaningful amount of money for this service. As you can see, this idea had some holes, but I didn't worry about that – I just got to work.

I applied to my university's accelerator program, got in, and worked on this idea full time for 3 months. I got two clinics onboard, built the entire web app myself, and won some competitions. Ultimately I never rolled it out due to concerns with storing PHI. I likely could have overcome this, but at 19 I really had no clue what I was doing.

Walk-In Express didn't lead to much. It did however get me my first job working in the healthcare industry as a Project Assistant, as I built a relationship with a few executives in the space.

Working in healthcare technology became my edge throughout in my career, allowing me to get a Senior Business Analyst job at 22 prior to finishing my degree and kicked off my product career. If you doubt the benefits of side projects, this in itself is a good enough case for trying.

Track Rite - 2018

Total revenue: $0 | Total users: 0

The next project I built was a task management app (like everyone else). Mine was a bit different - it was targeted at project managers who are used to managing nested tasks, or work backlogs.

My application allowed users to get reporting at each level or tier of this hierarchy.

Once again, I ran into the same problems. I had a rough idea of a problem I was solving, but no real evidence that anyone cared and no clarity on the value of solving it. I was more interested in building than actually solving customer problems.

This was probably the largest project I had built to date, so I did improve my technical skills a bit. I also hired a senior engineer part time to review my code and help me improve my technical skills.

Airbnb Analytics - 2020, 2021

Total revenue: $10,000 (split between me and my cofounder) | Total users: 50

Over the years, I tried multiple times to build an Airbnb analytics product with a good friend. Our first two attempts were in 2020 and 2021. This application was an Airbnb data product that helped hosts select the neighbourhoods they should list in.

The first few iterations of this product really didn't do much. We had a clear problem, but a poorly implement solution and no distribution. The first version was more of an internal tool to prepare reports, and we had less than 10 customers who ended up using them.

The second iteration was a tool that integrated with a third party data source and reformatted their data into a more user friendly report. This product was self-serve and had about 50 users. We made a total of $10k before the third party made changes that disallowed our integration. At this point we had to shut down the project.

Udemy Courses - 2021

Total revenue: $5,000 | Total users: 4,000

After the second failure of the Airbnb analytics project, I was extremely frustrated that I kept building products that had no users. I decided to not build another software product again until I could solve distribution.

For a while, I was unsure what to build next. I decided to go after something where distribution was solved for me, like a marketplace. This led to Udemy.

In the next few months, I created four courses, the most successful one being Power Automate Desktop for Beginners. I had over 4,000 students take my courses on Udemy and made close to $5,000.

The main benefit of Udemy was it forced me to think differently about products. Getting my courses into the hands of customers allowed me to learn more about the perceived value of a solution and the value of solving urgent and painful problems.

It was clear to me that Udemy customers didn't value my solutions very highly and that I wouldn't be able to scale this business very far. I needed to find a group of customers who had more urgent and painful problems to solve.

Pluralsight - 2022

Total revenue: $30,000 | Total users: 5,600

Pluralsight was a natural next step for me from Udemy. Pluralsight is a B2B marketplace for online courses. They contract expert authors to create content and provide the entire content library to more than 70% of the Fortune 500.

Working with Pluralsight was a multi-step process. First, I had to apply as an author. I went through a few rounds of interviews and had to submit a sample video using their branding and guidelines. Ultimately I was approved and able to start taking on work.

Pluralsight is pretty particular about their process – they have their own QA, slide templates, and even specific allowed animations. Building a course with them was very time intensive, with lots of back and forth. They also provide a list of available topics, so you may not always have the option of teaching topics you're passionate about.

From Pluralsight, I learned how to create high quality content (and that their style was too formal for me). There was a notable increase in quality from Udemy to Pluralsight, which I brought with me to Maven.

I created a total of four courses with Pluralsight and earned roughly $30,000. This was the first time I made actual money in 5 years of side hustling.

Airbnb Analytics - 2023

Total revenue: $100,000 | Total users: 200

Once again I was drawn back into working on Airbnb analytics. My friend had built a following in the space and found a new data source that would allow us to control the end-to-end process of report generation. This time, we were able to build a fully functional application that had no external dependencies.

We quickly scaled this to over $100k in revenue, but once again hit a wall with access to data. Our prior data supplier had a competitive customer and no longer wanted to work with us. Other suppliers cost more than $20k per month, which forced us once more to close down this offering.

You can read the full story here: https://blog.techforproduct.com/p/how-i-grew-my-saas-to-100k-in-6-months

Maven - 2023

Total revenue: More than my day job | Total users: 1500 paid, 25K+ free

Finally, that leads us to where I am today. I launched a Maven course (Technical Foundations for Product Managers) in mid 2023 to very little fanfare. In fact, my first cohort only had 11 people and I made less than $300.

I consistently improved the course, worked on my own branding, and kept teaching. The cohorts grew in size, more people took notice, and eventually Lenny reached out to me to write an article for his newsletter. From there, I've continued the momentum by building more products, launching a community, writing on Substack, and posting on LinkedIn.

Maven quickly grew to earn more than my day job, but I kept working for more than a year to ensure my growth on Maven was sustainable.

This time, I was solving a clear problem for an audience that valued the solution and had a clear distribution channel. These three components took me more than 7 years to get right, but now I never launch a product without a very clear idea of how each of these elements will work.

What I learned

Looking back at these projects, there are a few patterns that separate the successes from the failures:

Problem, audience, and distribution all matter. Every successful project had a clear problem I was solving, an audience that valued the solution highly, and a way to reach that audience. The failures were missing one or more of these components.

Build for customers, not for yourself. My early projects were driven by what I wanted to build, not what customers actually needed. This is a common trap for technical people.

Own your dependencies. Both Airbnb analytics failures came down to relying on external data sources I didn't control. If your business depends on something you don't own, you don't really have a business.

B2B customers pay more. The jump from Udemy to Pluralsight to Maven shows how much more valuable B2B customers are compared to consumers.

Next Project - 2025

I have a few projects in the works that I plan to launch in the later half of this year.

My plan is for the next set of projects to 2-3x the growth of my business – all by delivering more value, solving a bigger problem, and nailing the distribution. These bets may not work, but I’ve learned how to identify and mitigate risks earlier through my many attempts.

If you learn anything from this post, I hope you learn that progress is non-linear and growth takes time. Instead of worrying about how you'll make millions online, just ship something. You'll learn from your mistakes, improve, and try again. Hopefully it doesn't take you seven years, but even that's better than not making any progress at all.

Happy side-hustling!

Subscribe now

If you’re not paying close attention, you may have missed a critical update to ChatGPT and Claude that enables a brand new distribution channel: Integrations.

OpenAI announced support for remote MCP integrations on June 4th. Not to be outdone, Claude announced the same on June 18th.

In this post, I’ll describe what MCP is, it’s current state of support, and how you can start to think about incorporating MCP support into your product. I’ll also share a vision of the future, including parallels to the early days of the app store and the potential for tool sprawl within ChatGPT and Claude.

Let’s dive in!

What is MCP?

MCP (Model Context Protocol) is a standardized protocol for communication between agents and external servers. The role of MCP is to define the common ideas and requests that an agent can use. These include:

• Tools: actions the agent can take

• Prompts: templated messages

• Resources: files and other static data

Today, tools are the most commonly implemented feature of MCP. Think of asking ChatGPT to pull your financial projections from Google Sheets and forecast three new scenarios. The ability for agents like ChatGPT and Claude to interact with your data where it already lives opens up a whole new set of possibilities.

Here’s how it works:

1. A user makes a query inside of ChatGPT or another agent.

2. The agent checks the MCP servers it's connected to and determines if any tools would be relevant in resolving the request.

3. The agent constructs the request to the MCP server by calling the tool and adding any necessary parameters. The MCP server can either resolve the request itself, or proxy the request back to a regular web server to interact with your existing API.

4. The chain gets resolved, with a response back from the app server to the MCP server, MCP to the agent, and finally the agent uses the returned information to write a response to the user.

Here’s a quick example of running this through in Claude with an MCP connection to Gmail.

In this example, I provide Claude a query. It uses this information to send a request to a Gmail MCP server with a tool call for searching messages. This likely hits an existing Gmail API, returns the content, and then Claude summarizes the information for me.

For most of the past year, MCP servers were run on local machines and products like ChatGPT did not support MCP connections.

In June, that changed with the addition of remote MCP servers. Remote MCP is simply an MCP server that’s hosted on the internet, rather than on your computer. The main difference is the setup; remote MCP allows regular users to paste a link and connect their favourite tools. It also allows you to setup authentication, ensuring user data stays secure.

MCP is quickly becoming much more popular. This image shows the growth of popular libraries developers use for building MCP servers, a proxy for the growth rate of MCP servers being built.

As a comparison, I’ve included the growth of Express JS, one of the most popular frameworks for building regular web servers.

Current state of remote MCP support

As exciting as remote MCP support seems, it's still early days. Today, Claude allows any Pro user to add an external URL as an MCP server. The server must support OAuth, even if it returns a public access token.

Here’s what the configuration looks like:

ChatGPT makes MCP connections a little more challenging. First, the UI to access custom connectors is buried behind first party connections. Second, these connections only work in Deep Research mode, meaning most users would never see them used. Finally, this setting is currently only accessible to those on a Team plan.

This is unfortunate, as ChatGPT is the dominant consumer application and exposing your product through it would be a meaningful way to add new value and acquire new customers.

Here’s the process to add a connection from a user’s perspective:

What MCP means for you

Brian Balfour recently shared a great post on the next great distribution shift. He believes that these connections within AI agents represent the next wave of distribution, after which OpenAI and Anthropic will commoditize the most popular use cases. Here’s what he has to say:

“The stampede is coming. If I’m right, in six months, it’s likely every SaaS product and consumer application will be rushing to complete a ChatGPT integration. In twelve months, users will expect it. In eighteen months, the platform taxes will arrive. In twenty-four months, the graveyard will be full.”

I share a similar perspective to Brian, but I think there will be a greater variety of outcomes based on the types of applications built. I think we’ll end up with roughly four types of MCP applications:

1. Small utilities & apps

2. Mega corp integrations

3. Data-driven apps

4. New and unknown

Small utilities & apps

Think early iPhone apps, like Shazam. These will likely be the first to get cannibalized by the platforms themselves. Why maintain a separate tip calculator app when ChatGPT can do math? The barrier to entry is low, but so is the defensibility.

Mega corp integrations

Companies like Salesforce, Microsoft, and Google will build comprehensive MCP integrations that become table stakes. These integrations will be strategic partnerships rather than acquisition targets, as the platforms need these relationships more than they need to own the functionality.

Data-driven apps

Applications that primarily provide access to proprietary data sets or specialized workflows. Financial data providers like Bloomberg, specialized databases like Crunchbase, or industry-specific tools will maintain value through their unique data and domain expertise.

New and unknown

The most interesting category will be entirely new types of applications that wouldn't make sense without AI agents. These might be workflow orchestrators, multi-app data synthesizers, or entirely new product categories we haven't imagined yet.

The winners in this space will likely be companies that can aggregate multiple data sources or provide comprehensive workflows rather than point solutions. Just as we saw consolidation in the mobile app ecosystem, we'll probably see similar patterns emerge with MCP integrations.

If you're considering building an MCP integration, here are some questions to guide your strategy:

Is your product primarily about data access or workflow? Data-heavy products are more likely to maintain long-term value through MCP than simple utility functions.

Can you create network effects? Integrations that become more valuable as more people use them (like collaboration tools) have better defensibility.

How easily can your core functionality be replicated? If your main value prop can be built into the AI platform directly, consider focusing on more complex, differentiated features.

What's your relationship with the platform? Large companies should pursue strategic partnerships, while smaller companies might focus on becoming indispensable before getting acquired or copied.

MCP represents a fundamental shift in how software is distributed and consumed. Just as the app store changed mobile development and the web transformed desktop software, MCP could reshape how we interact with digital tools entirely.

Subscribe now

Watch this step-by-step video to get your own Figma components converted to code with MCP!

One of the biggest barriers to effective AI prototyping is the gap between your polished Figma designs and the generic components that AI tools generate by default. What if you could bridge that gap and use your actual design system components in tools like Bolt, Replit, or v0?

With Figma's new MCP (Model Context Protocol) server integration, you can convert your Figma components directly to React code and use them in any AI prototyping tool. In this guide, I'll walk you through the complete setup and show you how to maintain design consistency across your prototypes.

What is Figma's MCP server?

Figma's MCP server is a bridge that connects your Figma design files to AI coding tools like Cursor, allowing you to extract component code, variables, and images directly from your designs. Instead of describing what you want to an AI tool and hoping it gets your design system right, you can pull the exact specifications from Figma.

The MCP server exposes four key functions:

• Get Code: Retrieves React code based on your Figma component

• Get Variable Definitions: Pulls design tokens and variables

• Get Code Connect Map: Enterprise feature for component mapping

• Get Image: Extracts images and assets

Setting up the integration

The setup requires three components: Figma with MCP enabled, an AI coding tool (like Cursor), and proper variable usage in your design system.

Step 1: Enable MCP in Figma

In Figma, navigate to the dropdown menu in the top left, select Preferences, and toggle on Enable dev mode MCP server. You'll see a notification confirming the server is running on localhost with a specific port.

Step 2: Configure your AI tool

The setup varies by tool, but I'll focus on Cursor since it has excellent MCP support. In Cursor:

1. Go to Cursor Settings

2. Navigate to Tools and Integrations (formerly called MCP)

3. Add the Figma configuration:

{

  "mcpServers": {

    "Figma": {

       "url": "http://127.0.0.1:3845/sse"

    }

  }

}

Once added, you'll see a green indicator showing Figma is connected and available as a tool.

You can check out the docs here for full details: https://help.figma.com/hc/en-us/articles/32132100833559-Guide-to-the-Dev-Mode-MCP-Server

Step 3: Use variables in your design system

This step is critical and often overlooked. Your Figma components must use variables for colors, typography, spacing, and other design tokens. The MCP server relies on these variables to generate accurate code.

Without proper variable usage, you'll get generic code that doesn't match your design system specifications. Here’s the exact guidance shared by the Figma team:

Step 4 :Converting components to code

Once everything is set up, the conversion process is straightforward:

1. In Figma, select your component or component set

2. Copy the link to selection (right-click → Copy link)

3. In Cursor, paste the Figma URL directly into the chat

4. The AI will automatically detect it's a Figma link and use the MCP server to extract the component code

The AI will generate a React component that includes:

• Design tokens from your variables

• All component variants and states

• Proper styling using your design system values

• TypeScript interfaces for component props

Example: Converting a badge component

Let's walk through converting a badge component with multiple states. In Figma, I have a badge component with variants for different types (default, success, warning, error) and styles (filled, outlined).

When I paste the Figma URL into Cursor, it calls the Get Code, Get Image, and Get Variables actions. It generates the following components:

The generated component includes all the design tokens, proper state management, and matches the Figma design pixel-perfectly. The SVG icons are a little off, but could be corrected with additional prompts.

Common patterns and best practices

Start small and iterate

Don't try to convert your entire component library at once. The conversion time scales with the number of frames in your selection. A component with 5-6 variants might take a minute, while one with 50+ variants could take 5+ minutes just for the extraction step.

Use consistent naming conventions

Ensure your Figma component names match the naming you want in code. The AI will use these names to generate component and prop names.

Leverage component sets

Figma component sets translate beautifully to React components with multiple variants. Structure your components in Figma the way you want them to work in code.

Refine with prompts

If the initial conversion isn't perfect, use specific prompts to refine the output:

"Update the badge component to use the exact color tokens from Figma"

"Ensure all hover states match the Figma interaction design"

Integrating with AI prototyping tools

Once you have your converted components, you can use them in any AI prototyping too using Github. Simply push your converted components to a GitHub repository, then use the Github import feature to pull the components into tools like Replit and Bolt.

Putting it all together

Converting Figma components to code removes the guesswork from AI prototyping. Instead of describing your design system and hoping the AI interprets it correctly, you can provide exact specifications that maintain consistency across all your prototypes.

This approach is particularly powerful for:

• Design system maintenance: Keep prototypes aligned with your design standards

• Stakeholder demos: Show realistic prototypes using actual brand components

• Developer handoff: Generate code that developers can actually use in production

• Rapid iteration: Test design changes quickly without rebuilding components

The key is starting with a well-structured design system in Figma that uses variables consistently. Once that foundation is in place, converting components becomes a matter of copying and pasting URLs.

Remember that this workflow works best for teams with established design systems. If you're still building out your component library, focus on creating a few core components with proper variable usage before attempting large-scale conversions.

We kept hearing the same thing from our readers and students:

1. “I want to meet other people who are tinkering with AI.”

2. “Where can I find real AI workflows that actually work?”

3. “I want to see what AI apps people have built and how they did it.”

So Peter and I are starting this Slack community to help you use AI to save time, get more done, and build great products.

Here's what you get as a community member:

1. Our best AI resources for free including Colin’s Technical Foundations for PMs course (4.7 stars, 84 lessons), Peter’s AI prompt library (24+ go-to prompts), and a new prompt library for AI apps (see below).

2. Live workshops with AI experts, starting with an AMA with Peter and me this Friday at 3:30 pm pst.

3. Meet other product leaders and founders from Google, Meta, Netflix, and more who have taken our courses and are AI enthusiasts.

Upgrade to paid to get a link to join the community right away.

Subscribe now

What's included: Full course and prompt libraries

Here's what we're making available to community members at launch:

1. Colin’s Tech Foundations for PMs course (84 lessons)

Colin has taught this course to 900 PMs with a 4.7 rating and he’s generously making it available to community members for free. Above is a snapshot of what the course covers (modules include video and text walkthroughs).

2. Peter’s battle-tested AI prompt library

This library includes 24+ prompts that I use every week for product, creator, and personal tasks. Peter updates this library regularly — no fluff, just prompts that work.

3. New AI prototyping prompt library

This library includes one-shot prompts to build our favorite apps with AI. It’s still a work in progress but we’re looking forward to improve it with your help.

Look forward to seeing you in the community!

Subscribe now

The traditional product development lifecycle hasn't changed much: What has changed is how we can leverage AI prototypes to get better and faster insights within each stage.

Let’s walk through each phase of product development and how you can start leveraging AI prototyping to accelerate exploration and delivery.

Discovery

During discovery, you're exploring problems and iterating on potential solutions. Traditionally, this meant sketches, wireframes, and lots of imagination when presenting to stakeholders. With AI prototyping, you can build functional prototypes that let you actually experience the solution. This transforms discovery from theoretical discussions to hands-on exploration.

For example, let’s say you're a PM at Reddit exploring an AI-powered Q&A feature. Instead of just describing it in a PRD, you can just build it.

In less than 5 minutes, you have a working prototype that demonstrates:

• How the UI might look

• The actual user flow

• How citations could work

• What information architecture makes sense

At this stage, you want to use AI to test multiple options quickly and not get tied down to any single solution. It's important to not get attached to your ideas early just because they’re higher fidelity.

To nail discovery with these tools:

1. Start with the core interaction Don't try to build everything. Focus on the main user action. For Reddit Answers, that's asking a question and getting an answer.

2. Use real-looking data Nothing kills a prototype faster than "Lorem ipsum" content. Use realistic questions and answers that stakeholders might actually search for.

3. Keep fidelity low (intentionally) During discovery, you want feedback on the concept, not the pixels. Don’t spend too much time or effort on matching your exact branding.

4. Build multiple variations quickly The power of AI prototyping is iteration speed. Build 3-4 different approaches in the time it used to take to sketch one. Try different layouts, flows, or feature sets.

Roadmap & Alignment:

When you're aligning stakeholders on roadmap priorities, a polished prototype can be worth a thousand slides. AI tools excel at creating high-fidelity prototypes that look like finished products. Once you’ve settled on a solution we think is close to realistic, we can build a more polished version for internal communication.

Here’s the same Reddit Q&A feature, just with better UI and animations:

For executive and senior stakeholders, you want to make it clear this is a prototype and the final product may differ. The goal is to communicate the idea without distracting anyone with visual inconsistencies.

To create a higher fidelity prototype:

1. Use your actual design system Spend 30 minutes building a component library inside an AI prototyping tool – you'll use it for months.

2. Show the feature in context Don't prototype in isolation. Include your product's navigation, headers, and other UI elements so stakeholders can visualize how it fits.

3. Add micro-interactions Small touches like hover states, loading animations, and transitions make prototypes feel real. These details build confidence in your vision.

4. Include edge cases Show what happens with no results, errors, or long content.

Solution Testing

The biggest shift in solution testing is that you can now test with prototypes that feel like finished products. Users can't tell the difference, which means you get authentic feedback.

This requires preparing a few sample workflows and populating realistic sample data. For Reddit Answers, we could put this in front of users and gather real insights about:

• What questions they naturally ask

• Whether the UI is intuitive

• How they interact with citations

• Their satisfaction with AI-generated answers

You can also add any product analytics tools or external solutions directly to your prototype. This allows you to record the exact interactions users took inside the prototype, reducing your need to take detailed notes during a call and allowing you to easily share this data with your team.

Here’s an example of Posthog events and recordings I’m collecting on a prototype:

To make sure it's ready for testing with customers:

1. Make it feel production-ready Users give different feedback on rough prototypes versus polished ones. Use high-fidelity prototypes to get reactions to the actual experience, not the prototype quality.

2. Include enough depth Build out 2-3 common user paths completely. Users should be able to explore naturally without hitting dead ends.

3. Add analytics from the start. Interaction tracking and session recordings make it easier to share information with your team later. Use tools like Posthog for this.

4. Test your riskiest assumptions first For Reddit Answers, the big risk might be trust in AI-generated content. Design your test to specifically probe this concern.

Engineering Handoff

It’s important to remember that the code generated by AI prototyping tools is mostly useless to your engineering team. It doesn’t have any context on how your code base works, how to structure files, or even if it's using the same programming language.

Where it can be useful is to drive conversation on requirements and to document specific interactions. For example, our Reddit prototype might prompt the following questions from engineering:

• What does the accuracy score mean?

• How will it be generated?

• What external sources should be used?

• Is there any content within Reddit that should be excluded from answers?

• How should answers be vetted before being included in the AI response?

Using the prototype as an artifact for communication can drive better discussion and collaboration between design, product, and engineering.

As a bonus, you can also hand off exact requirements for small UI interactions, like hover states and animations. If we wanted this exact loading state from the prototype, the code is actually a useful starting point.

To get the best handoff with engineering:

1. Don’t assume the code is valuable: Share the code via Github or a file extract, but let the engineering team take what they want from it

2. Use system prompts: To get more useful code, have the engineering team write a system prompt that pushes the AI to use your engineering patterns

3. Drive rich conversations: Bring your prototype with you to scoping and use it as the primary conversation piece instead of your PRD

4. Use interactions: Prototype the exact loading states, animations, and empty states you want to save time and provide more clarity

Putting it all together

AI prototyping isn't just about building things faster – it's about fundamentally changing how we validate ideas and communicate vision. When you can go from idea to functional prototype in minutes, you can:

• Test 10x more ideas in the same time

• Get real user feedback before writing a single line of production code

• Align stakeholders with experiences, not explanations

• Surface technical questions before engineering starts

• Hand off working code that engineers can build from

The teams that master this workflow will ship better products, faster. The tools are here. The only question is: what will you build first?

Subscribe now

Before ChatGPT, a few curious developers had access to a brand new AI model from OpenAI: GPT-3. I was one of those developers.

This is the story of how I built my first AI app (back in 2022, before it was cool), scaled to 4,000+ users, and sold — all in a few months.

Let’s dive in.

The Plan

This product didn’t come about the typical way. I had no go-to-market plan, no customer interviews, and it was the first time I worked with a generative AI model.

I began down the road of building this product simply because I had early access to GPT-3 and thought it would be fun to build something.

At first, I was just messing around with the model. Once I had a good understanding of its limitations, I started brainstorming products I could build. I had a few criteria:

1. Built-in distribution - I didn’t have time or money to market the product myself

2. Extremely small scope - One high value feature

3. Easy to monetize - I wanted customers who were willing to pay

To satisfy these, I thought the best approach would be to build into an existing marketplace – something like the Shopify app store. Luckily for me, Saas Marketplaces has a complete list of marketplaces you can easily build on top of. Shopify would likely have been the best bet but their app store was already crowded with AI writing services. I decided to go for the next best thing - Wix.

Once I decided on building a Wix plugin, I spent a few hours playing with Wix’s product. I wrote blog posts, set up an ecommerce site, and generally looked for points of friction. The thing I found most annoying was adding a new product – you’re presented with this lengthy form that requires 30+ minutes to complete just to add a new product.

Given many ecommerce brands frequently change their offerings, I thought writing product descriptions automatically could be a useful way to leverage GPT-3.

So now I had a plan:

• Build a Wix plugin

• That helps ecommerce owners save time by automating product copy

• So that they can spend time on more important issues

And so Product Description Generator was born.

Here was the full plan:

The Build

This app was pretty straightforward to build. Users would provide a quick description of the product via my app, which I would send over to GPT-3. OpenAI would return the description for the user to edit or save.

Here’s how it worked on the technical side:

1. The user signs up for a free trial. My app authenticated them with the Wix credentials, ensuring the sign up experience was smooth

2. My app fetches their existing products from the Wix API and displays them in a list

3. The user selects a product, enters a description, product type, and tags, then clicks Generate

4. My app sends the information to OpenAI and receives a product description in response.

5. The user can edit the description and save to the associated product

6. On save, my app calls the Wix API to update the product description in their ecommerce store

The most complex part was the Wix integration. Their documentation was not the best, so there was a lot of trial and error in setting up the correct requests to authenticate the user and save the new description. In addition to the basic functionality, I also had to add a credit system. Free users were assigned 5 credits to use and could purchase an additional 100 ($12) or 300 ($20) credits per month. This meant I had to have background jobs that checked the users’ status and applied the correct number of credits at the beginning of each month, and that I properly handled their credit amounts when generating new product descriptions.

Partway through this project I hit a roadblock - each request to OpenAI cost about $0.03. OpenAI’s charges would cost me $27 to generate 300 descriptions but I was only charging $20!

Rather than increase my prices, I looked for ways to get more value out of each request. I discovered I could have OpenAI generate all 3 descriptions in a single request and split them by a special character. Then, I could process them in my server and display them properly as 3 separate options. Now, 300 credits would only cost $9 and I had $11 of margin to work with.

Here’s what my final prompt for GPT-3 looked like:

I used a technique called one-shot prompting, where you provide the model with a single example of what a “good” output looks like. This helps improve performance without adding complex technical steps like fine tuning.

The descriptions were preceded by a pipe character (|) which allowed me to split the line and grab the description.

Knowing what I do now, I would have used xml tags instead to format the prompt. It would have made splitting the text more reliable and allowed me to be more precise in my instructions.

<Instructions>
Given information about a product, write three compelling product descriptions that are at least one paragraph long.
</Instructions>
<Example1>
 <Input>

Details:Classic yet stylish, these jackets are ideal for any situation.   The warm and comfortable woolen fabric easily adjusts in size.
  
  Tags:Cotton, Limited Edition
  
  Type:Coat

  </Input>
<Output>

 <Option1>
Elevate your everyday style with our Limited Edition Classic Coat. Meticulously crafted for the discerning individual, this versatile jacket seamlessly transitions from casual daytime outings to sophisticated evening events. The premium woolen fabric provides exceptional warmth while maintaining breathability, ensuring your comfort in changing weather conditions. With its adjustable sizing feature, this coat adapts perfectly to your silhouette, offering a tailored fit that moves with you throughout your day. A timeless investment piece that will remain a staple in your wardrobe for years to come.
 </Option1>

  <Option2>
Embrace the perfect blend of tradition and trend with our Cotton Limited Edition Coat. This exceptional outerwear piece combines classic silhouettes with contemporary sensibilities, creating a jacket that's truly timeless yet distinctly modern. The warm woolen construction wraps you in luxurious comfort while the innovative adjustable sizing ensures a flattering fit for every body type. Whether paired with jeans for a casual weekend look or layered over business attire, this versatile coat effortlessly elevates any ensemble. Make a subtle statement with this exclusive piece that balances understated elegance with practical design.
 </Option2> 

  <Option3>
Discover unparalleled versatility with our signature Limited Edition Coat. Designed for the dynamic lifestyle of today's fashion-conscious individual, this exceptional jacket serves as the perfect companion for any situation life throws your way. The premium woolen fabric delivers substantial warmth without unnecessary bulk, while the thoughtfully engineered adjustable sizing ensures a customized fit that honors your unique silhouette. Crafted from select cotton and available in strictly limited quantities, this coat represents not just remarkable quality, but genuine exclusivity. An investment in enduring style that seamlessly bridges the gap between classic appeal and contemporary relevance.
 </Option3>

</Output>

How It Went

After working on Product Description Generator part-time for about 3 months, I was ready to launch. I filed tickets with the Wix App team and OpenAI team, picked a launch date, and waited anxiously for my first customers. At this time, OpenAI was manually reviewing and approving every app integrating with their API to ensure you were following their guidelines. They even had a separate endpoint you had to integrate with that would check if the content generated by GPT3 was harmful or not.

Eventually, I got through the approvals and had a launch date – but no marketing plan. On launch day, a slow trickle of users started showing up and using the app. First it was 10, then 20, then 100.

It was working!

Over the next two months, over 4,000 users signed up for Product Description Generator and I reached $400 per month in revenue. Most of my time was spent fixing bugs and responding to customer support requests. My initial joy at building a real SaaS app was slowly fading as I realized I had no future plans or way to expand the app. One day, after a particularly frustrating bug was finally solved, I decided I to look into selling the app.

I listed Product Description Generator on Acquire.com, expecting very little interest. To my surprise, I very quickly had dozens of inbound requests to learn more about the product. Within two weeks of listing I had sold Product Description Generator for low five-figures. The acquisition process was smooth and I handed off all the accounts and assets to the new owners.

And just as quickly as it started, it was over. I had fulfilled a life long goal of building a SaaS app, scaled to thousands of users, and sold it – all within four months.

What I’d Do Differently

Honestly, there isn’t much I’d change about this experience. I set out with the goal of building an AI product and was successful. Since 2022, generative AI has taken the world by storm and this product has lost most of its defensibility.

If I was still running this product, I’d continue to look for friction points in the user’s experience for managing ecommerce stores. I’d likely bundle together a few features that offer a similar value proposition (like generating product photos with the OpenAI’s new image gen models) and sell access to the set of features at a fixed price.

I think products like these are the best starting point for beginners – the built in distribution ensures you at least get off the ground and can meaningfully help you scale. There is a big difference between 0 users and 100+ users that is difficult to understand without experiencing it.

Did you enjoy this post? Make sure to hit subscribe for more!

Subscribe now

Subscribe now

Coding has quickly become the most valuable use case for AI, scaling companies to billion dollar valuations and pushing major brands like Canva and Figma to ship competitive products or risk losing their dominance.

In today’s post, we’ll do a deep dive into how AI coding tools work under the hood. We’ll explore different architectures for AI applications and how these popular tools might work.

Let’s dive in.

Types of AI Apps

Before diving into specific tools, it's important to understand that there are multiple approaches to building AI-powered applications. Three common patterns have emerged:

1. Simple Integrations

2. Single-Agent

3. Multi-Agent

Simple Integration

The simplest approach is a direct integration with an AI model. This is what you'd build by following my guide to building an AI feature: a client that sends requests to a server, which forwards them to an AI provider like OpenAI or Anthropic.

This pattern is perfect for simple products like chatbots or AI writing assistants. When people talk about building “AI wrappers”, this is what they mean.
There are really only a few parts of this pattern that require optimization:

1. System prompt

2. Examples / fine tuning

3. Evaluation and monitoring

A system prompt is the default prompt that the application provides the AI model on every request. Typically these are instructions that have been carefully crafted to provide the best possible output from the AI model.

For example, let’s say you wanted to build an ecommerce product description generator. Your system prompt might look something like this:

The first part of the prompt includes instructions. This can include techniques like setting the role (“You are an expert copywriter”) and setting constraints (“Return one sentence per product”).

Next we have examples. Adding a single example into the prompt is called one-shot prompting. You can add as many examples as you like, so long as you can fit the text in the context window. Remember that AI models have a fixed number of tokens or characters they can accept. When building AI systems, deciding on the correct context to provide is one of the most important and challenging steps.

Here’s the beginning of Bolt.diy’s system prompt – you can check out the full prompt here:

You are Bolt, an expert AI assistant and exceptional senior software developer with vast knowledge across multiple programming languages, frameworks, and best practices.

<system_constraints>

You are operating in an environment called WebContainer, an in-browser Node.js runtime that emulates a Linux system to some degree. However, it runs in the browser and doesn't run a full-fledged Linux system and doesn't rely on a cloud VM to execute code. All code is executed in the browser. It does come with a shell that emulates zsh. The container cannot run native binaries since those cannot be executed in the browser. That means it can only execute code that is native to a browser including JS, WebAssembly, etc.

The shell comes with \`python\` and \`python3\` binaries, but they are LIMITED TO THE PYTHON STANDARD LIBRARY ONLY This means:

- There is NO \`pip\` support! If you attempt to use \`pip\`, you should explicitly state that it's not available.

- CRITICAL: Third-party libraries cannot be installed or imported.

- Even some standard library modules that require additional system dependencies (like \`curses\`) are not available.

- Only modules from the core Python standard library can be used.

Additionally, there is no \`g++\` or any C/C++ compiler available. WebContainer CANNOT run native binaries or compile C/C++ code!

Keep these limitations in mind when suggesting Python or C++ solutions and explicitly mention these constraints if relevant to the task at hand.

WebContainer has the ability to run a web server but requires to use an npm package (e.g., Vite, servor, serve, http-server) or use the Node.js APIs to implement a web server.

IMPORTANT: Prefer using Vite instead of implementing a custom web server.

IMPORTANT: Git is NOT available.

IMPORTANT: WebContainer CANNOT execute diff or patch editing so always write your code in full no partial/diff update

IMPORTANT: Prefer writing Node.js scripts instead of shell scripts. The environment doesn't fully support shell scripts, so use Node.js for scripting tasks whenever possible!

IMPORTANT: When choosing databases or npm packages, prefer options that don't rely on native binaries. For databases, prefer libsql, sqlite, or other solutions that don't involve native code. WebContainer CANNOT execute arbitrary native binaries.

CRITICAL: You must never use the "bundled" type when creating artifacts, This is non-negotiable and used internally only.

CRITICAL: You MUST always follow the <boltArtifact> format.

Available shell commands:

File Operations:

- cat: Display file contents

- cp: Copy files/directories

- ls: List directory contents

- mkdir: Create directory

- mv: Move/rename files

- rm: Remove files

- rmdir: Remove empty directories

- touch: Create empty file/update timestamp

System Information:

- hostname: Show system name

- ps: Display running processes

- pwd: Print working directory

- uptime: Show system uptime

- env: Environment variables

Development Tools:

- node: Execute Node.js code

- python3: Run Python scripts

- code: VSCode operations

- jq: Process JSON

Other Utilities:

- curl, head, sort, tail, clear, which, export, chmod, scho, hostname, kill, ln, xxd, alias, false, getconf, true, loadenv, wasm, xdg-open, command, exit, source

</system_constraints>

In addition to the system prompt, production-ready AI systems need logging.

Logging allows you to view the results of an AI request in your production environment. Here’s a quick example of what logging looks like:

AI logging is usually called Tracing. The example above shows a sequence of steps performed by the AI system. This trace has steps for generating text and for calling a tool called DocumentSearch. Tracing is a critical tool for product teams to monitor the use of their production AI systems.

Now that we’ve reviewed the basics, let's talk about agents.

Single Agent

The differentiating factor between simple integrations and agents is tools. Where a simple integration only allows the AI system to return generated content, Agents enable AI systems to also take actions through a set of predefined tools. Tools are typically defined as a set of API calls the Agent can make.

For example, I can connect various tools to Claude Desktop through MCP, an API communication protocol. When I ask Claude to analyze my email broadcast open rates, it can pull the relevant data from Convertkit, create recommendations, and visualize the data for me.

Read more

Subscribe now

In early 2022, a friend of mine (we’ll call him Alex) approached me to work on a new product together. After running more than a dozen Airbnb’s himself, Alex had recently moved to a firm that professionally purchased and managed short term rentals. His role was to identify prospective properties, analyze potential cashflow, and ultimately determine which properties to purchase.

Alex had built a methodology for selecting properties and was creating free content on Youtube teaching others to do the same.

Our idea was simple: automate the data processing and provide clear step-by-step training.

The Plan

Here was our plan:

Our target persona was a multiple property owner who was looking to expand out-of-state. Ideally, they had experienced some of the challenges of property selection and understood that making the right decision could mean an additional $20k+ per year in profit.

We intentionally did not want to automatically recommend properties to purchase. Instead, we wanted to build a system that provided hosts the data and training they need to quickly assess a market. Although there were many competitors in the Airbnb data space, they all approached the problem from a pure SaaS perspective. They provided complex tools to manage data within their platform, but this required expertise and time from hosts.

Our product would be closer to a tech-enabled service. We would provide an extremely simple interface – select your city, generate the report, and get an export to Google Sheets. We would also provide detailed training and expert support from our team.

Distribution would be primarily through Youtube. Alex had a small following (~3K subscribers) in a very specific niche, so we felt confident we could convert a decent number of users. We priced each report at $1000 initially, with multiple reports bundled at a discounted price.

We expected to reach the $25k mark fairly quickly as we converted existing demand for Alex’s system, and saw an opportunity to scale well past $100k in 12 months time.

Our primary risk was the data itself. Airbnb does not make their data publicly available, so we were reliant on a 3rd party who had been collecting and reselling data.

The Build

As the technical partner on this project, it was up to me to build out the tooling and infrastructure needed. To start, we decided to only support the United States, as the vast majority of our demand was concentrated there.

Our data supplier provided us with 1.5M+ records every month with 65+ data elements per listing. We also had in-house data cleaning, validation, and aggregation steps to run per listing.

This was going to be a complex project.

Here’s how it worked:

1. Each month, our data provided dropped a 10GB CSV file in object storage (S3)

2. An automated data pipeline would pick up the file, clean it, and pre-compute values. Then, it would insert the records into a MongoDB database

3. Mongo would store all of proprietary property data, and a separate relational database would store all other data (users, accounts, reports they created, etc)

4. The user would navigate to the site, select a location, and generate a report. The application server would then grab the relevant data from Mongo, create Google Sheet, and insert the data. Then, we’d create a gSheet pivot table automatically to prepare the report.

5. Finally, we automatically added the user as an editor on the gSheet, which triggers an email to notify them the report was ready.

This backend of this product was fairly complex, but it was critical that we kept the User Experience simple.

We decided on a single page that linked out to your existing reports and allowed you to request new locations.

Scaling and security were fairly straightforward. We used GCP, Google’s cloud services. Our app server was hosted on App Engine, which allowed us to automatically scale servers based on demand. We ensured that all requests to our server had to be authenticated and from known URLs using whitelisting. Our Mongo environment was also hosted in GCP and was secured behind a private network – no one could access its contents directly.

Our S3 bucket was secured with a simple username and password, and we archived files monthly after processing.

How It Went

After spending ~4 months building, we launched an early access version to a few select customers who we thought would benefit most. We iterated on the product for about a month, then launched to a broader audience with a limited number of reports available.

Our sales far exceed our expectations, passing $100k gross in 2 months! 🎉

During this time, I was putting out a ton of technical fires (while working full time). I was working 12+ hours a day, fixing bugs between meetings, and generally just trying to keep the ship afloat. In case it’s not obvious, I’m not a professional engineer and built 100% of this product solo, so I constantly felt like I was making it up as I went.

Unfortunately, our success quickly dried up as we ran into a new problem – access to data. Our data provider was unable to continue working with us and other providers charged upwards of $240k per year for the same product. Changing providers would also require us to rework our data pipelines and transformations, creating weeks of new work.

We were also unsure if we’d be able to scale our go-to-market enough to maintain margins, given our new (very high) fixed costs.

Ultimately, we decided to shut down the product and Alex continued offering his product as service. At the same time, my live courses on Maven started to pick up and I decided to prioritize providing the best product I could to help other PMs become more technical.

What I’d Do Differently

Overall, building this product was one of the most fun experiences I’ve had in my career. Taking on the lead technical role was definitely a stretch for me, but we were able to make it work.

Having built 12+ products solo, here’s the 3 reasons why I think this one worked:

1. Clear distribution strategy - Alex had already spent 2+ years building trust and expertise in a very niche topic

2. Clear pain point - Multi-home hosts had experienced the pain of unprofitable properties and desperately wanted to avoid doing the same thing again

3. Simple product - We were able to deliver a clear, simple process that actually worked – something that was difficult to find on the market

If I was to do this again, I’d probably take the leap and purchase the data for $240k. I think we underestimated the size of this market and could have easily scaled this to $2-3M in revenue through channel partnerships with larger influencers in the space.

But, there’s always next time!

Did you enjoy this post? Make sure to hit subscribe for more!

Subscribe now

Subscribe now

Creating a prototype is exciting - you've turned your idea into something tangible that you can show to users and stakeholders. But there's a vast difference between a prototype that works on your machine and a production-ready application that can handle real users securely.

As a product manager who's never shipped an app before, the path from prototype to production can seem daunting.

Let's break down the five most critical steps to transform your prototype into a production-ready application:

1. Implement proper authentication and authorization on both client and server

Your prototype might use simple password checks or local storage to manage user sessions, but a production app needs robust authentication on both client and server sides. This double-verification approach is crucial for security.

On the client side, you'll implement UI components for login, registration, and password resets along with session management. But remember that any client-side code can be manipulated by users. This is why server-side authentication validation is essential.

Even if your client code checks for authentication, every API endpoint on your server should independently verify three things:

1. Is the user authenticated? (Do they have a valid session token?)

2. Is the token unexpired? (Has their session timed out?)

3. Is the user authorized for this specific action? (Do they have permission?)

For example, imagine your app has an API endpoint that lets users edit their profile. Your server code should look something like this:

This double-check approach ensures that even if someone bypasses your client-side authentication (which is relatively easy to do), they'll still be blocked at the server level.

2. Secure your secrets and API keys

Your prototype may have API keys, database credentials, and other secrets hardcoded directly in your application code. This approach is a security nightmare for production.

First, let's understand what counts as a "secret":

• API keys for third-party services

• Database connection strings

• OAuth client secrets

• JWT signing keys

• Encryption keys

• Admin credentials

These secrets should never be:

• Committed to your Git repository (even private repos)

• Hardcoded in your application code

• Stored in client-side code that gets sent to browsers

• Shared via email or messaging platforms

Instead, implement proper secrets management:

1. Use environment variables for server-side secrets. These should be set up in your hosting environment (like Netlify, Vercel, or AWS), not in your codebase. You can use a .env file for testing on your own computer and configure it to be ignored by Github with a .gitignore file
   

2. For frontend applications, create backend proxy endpoints. Instead of including an API key in your frontend code, create a server endpoint that makes the third-party API call on behalf of your client.
   

3. Set up monitoring for API keys. Set a fixed budget or number of requests so you can be notified if traffic exceeds your expectations.
   

4. Use the principle of least privilege: each secret should have only the permissions necessary for its function, not admin-level access.
   
   

Here's how you might handle a third-party API call correctly:

Proper secrets management is often overlooked but is one of the most critical aspects of production security.

3. Never trust client-side input

In your prototype, you might assume users will provide reasonable, well-formatted input through your UI. In production, you need to assume the opposite.

Any data coming from the client side – whether from forms, API calls, or URL parameters – should be treated as potentially malicious. This includes data from your own UI, as attackers can bypass your interface entirely and send requests directly to your API.

There are two key practices to implement:

Validation ensures data meets your requirements before processing:

• Is the email actually an email?

• Is the user ID in the correct format?

• Are all required fields present?

• Do numeric values fall within acceptable ranges?

Sanitization removes potentially dangerous content from input:

• Stripping HTML tags from text that will be displayed

• Escaping special characters to prevent injection attacks

• Normalizing data formats (like phone numbers or dates)

Implement validation and sanitization at both the client and server levels:

SQL injection and cross-site scripting (XSS) attacks often result from failing to properly validate and sanitize input. These vulnerabilities can lead to data breaches or account takeovers, so this step is crucial for production readiness.

4. Set up comprehensive monitoring and alerting

Your prototype probably doesn't need monitoring – when something breaks, you're there to fix it. But a production app needs automated monitoring to identify issues before users report them or, ideally, before users even notice.

Monitoring should catch high priority production issues like crashes and collect data on bugs and poor UX. You can use tools like Sentry to monitor your application performance and PostHog to collect data on user behavior.

Here’s an example of what monitoring looks like with Sentry:

In addition to monitoring, you’ll likely want to set up alerts. These notifications will send you an email when a critical issue has occurred. Set up alerting thresholds carefully – too sensitive and you'll face alert fatigue, too relaxed and you'll miss critical issues. Good starting points include:

• Error rates above 1% on critical paths

• Response times exceeding 2-3x normal

• Any failed health checks

With proper monitoring in place, you can catch issues early, understand your application's behavior patterns, and make data-driven decisions about what to optimize.

5. Secure integrations with third-party services

Your production app will likely integrate with payment processors, email services, analytics tools, and other third-party providers. Each integration is a potential security vulnerability if not implemented correctly.

For payment processing, never handle credit card information directly unless absolutely necessary. Instead, use services like Stripe that provide secure elements to collect sensitive information without it touching your servers.

For email integrations, use established providers with proper authentication and ensure you're following best practices for email delivery and security.

When integrating with APIs, implement these security measures:

1. Validate webhook sources: If a service sends you data via webhooks, verify the sender using signatures or shared secrets.

2. Implement rate limiting: Prevent abuse by limiting how frequently your endpoints can be called.

3. Use minimal permission scopes: When connecting to OAuth services, request only the permissions your application needs, not everything available
   

4. Handle API failures gracefully: Third-party services will eventually fail or change. Design your application to degrade gracefully when this happens.
   
   

Remember that your application is only as secure as its weakest integration. Review each third-party service carefully and follow security best practices for each.

Putting it all together

Moving from prototype to production requires careful attention to security, reliability, and maintainability.

By implementing proper authentication and authorization on both client and server, securing your secrets and API keys, validating and sanitizing all input, setting up comprehensive monitoring, and securing your third-party integrations, you'll build a solid foundation for your production application.

Subscribe now

There’s been some mixed opinions recently on if AI coding tools can build real software. In this post, I thought it would be fun to share what I’ve built so far as inspiration on how far you can go. We’ll start with the simplest apps and increase the complexity as we go.

Substack Image Resizer + Video to GIF Converter

These two apps are quick utilities I made for myself to solve a recurring problem. The first was that Substack has specific file sizes it wants for uploaded images. I typically design my images in another program without thinking about dimensions, and converting the cover photo to Substack’s preferred size was a nuisance.

Here’s what I built:

This app takes in an image, detects the background color, and creates resized images for each of Substack’s publication styles. Then, I just download the image and upload to Substack!

The next problem was that Substack has very small file size restrictions for GIFs. I actually spent multiple hours trying different tools to convert videos, only for Substack to reject them.

Finally, I decided to solve this myself:

Each tool only took a few prompts and worked better than any solution I was able to find. I now use these weekly to share content with all of you!

The stack for both of these is very similar:

1. Python

2. Streamlit

3. Deployed via Replit

Python excels at data driven or operational tasks like handling image and video files, so it was a good choice. As of today, Replit is still the only platform that supports Python projects.

AI Prototyping Showcase

As part of my Maven course, I decided to try a User Generated Content loop. The basic idea here is that I would find something students can submit that would drive impressions, more people would see the course, and I’d increase enrollments. Those new students would submit content, and the whole loop would continue.

The best idea I had was a collection of student submitted vibe coded projects – they’re fun to explore and give students a good understanding of what they can ship by the end of the course. (Check it out here)

Features include multiple image files, Youtube embeds, voting, and a project submission.

To build this, I started with Bolt and pulled many components from 21st.dev. Once I was happy with the client side app, I exported the code to my computer and continued with Cursor to set up the server and database.

For this project I used an Express server and PostgreSQL db. The whole app is stored in Github, which triggers automatic deployments to Railway. This is my preferred stack at the moment – Railway provides an easy hosting platform that can host everything (client, server, db) with updates pushed directly from Github.

Maven Referral System

Another growth loop Ive explored is referrals. At the moment, Maven does not have a referral system, so I decided to build my own. This app allows users to create an account, generate a unique referral code, and track page views with their links.

I built this entirely in Replit. It includes a Stripe integration, auth, and events storage for analytics. The best part is that the referral link generation is automatic, saving me time from creating these manually for students. This app probably took me 4-6 hours in total and has driven about a dozen enrollments so far.

AutoLive.ai

AutoLive is one of the more complex apps I’ve built. I started this project in Lovable and swapped over to Cursor about 70% of the way through the project. Because Lovable has a 2 way Github sync, switching between tools is extremely easy.

AutoLive is basically a custom version of Google Slides for live courses. I can do all the normal stuff - add text, images, etc. In addition, I can run polls, Q&A, and embed other sites.

The embed part is really the main feature I wanted. It allows me to create other custom content with tools like v0 and Bolt, deploy that content to the web, and then add it as a slide in my presentation. I have a few really cool slides, like an API request tool that has a built in AI assistant.

This project also includes a bunch of realtime features – for example, when I swap slides, it automatically moves all students with me. I can see how many students are connected to the session and have real time votes and questions. The backend for this project is entirely hosted in Supabase.

Putting It All Together

Hopefully this quick overview of some of the things I’ve built has helped show you that these tools are good enough to build your own apps.

Yes, you need to be more technical to really make fast progress, but AI enables anyone to make progress. I’d still encourage you to learn the fundamentals, but if vibe coding gets you started, then dive right in!

Subscribe now

One of the main challenges when using tools like Bolt, v0, and Lovable is getting a consistent look that closely matches your product. In this short post, I’ll walk through how you can create a reusable component library to quickly assemble unique prototypes over and over.

We’ll be using Airbnb and v0 as an example.

Step 1: Planning the Component Library

First, I provided v0 with the following prompt with a screenshot of the Airbnb home page:

You are tasked with creating a component library based on a screenshot, using React and Tailwind CSS. All components should be custom-made to match the screenshot as closely as possible.

Follow these instructions carefully: 
Analyze the provided screenshot.Identify distinct UI components in the screenshot. These may include, but are not limited to:
Buttons
Input fields
Navigation bars
Cards
Modals
Typography elements

For each identified component: a. Create a React functional component b. Use Tailwind CSS classes to style the component, matching the visual design in the screenshot c. Ensure the component is responsive and accessible d. Add any necessary props for customization e. Include a brief comment describing the component's purpose

After creating all individual components, the app.tsx file should import and display all components. Do not try to match the screenshot ui – only display a list of components.

Remember to use only custom-made components and Tailwind CSS classes. Do not use any external libraries or pre-built components. Strive to match the visual design in the screenshot as closely as possible while maintaining good coding practices and component reusability.

This prompt tells v0 to focus on building individual components, rather than replicating the actual layout from the screenshot. We end up with a list of components like this:

From the initial set of components, I continued passing in additional screenshots until I felt I had captured enough.

Here’s the full set:

Note that these components don’t match one-to-one on the initial prompt, but we can continue to improve on them if we want.

Step 2: Refining UI Components

The wonderful thing about this approach is that it allows you to make visual edits to your components before you use them in an actual prototype. This lowers the complexity of making changes and makes it much more likely your prompts will actually work. For example, I used the visual inspector to improve the Airbnb header. Here’s a quick before and after:

Trying to make similar changes in an existing prototype can sometimes be a frustrating battle of pushing the AI to make the correct changes to the correct files. Because we start with independent component files, v0 has no problem identifying and changing one file at a time.

Step 3: Building With Our Components

Now we’re ready to use our components. Before continuing, make sure you fork the project to create a new copy. This allows you to return back to your component library as often as you want to create new ideas without redoing the work.

In my case, I asked v0 to imagine a new and creative homepage for Airbnb using my components. Here’s what I got:

Results and Benefits

Now that we have our component library, we can have a centralized source of truth for our prototypes. At any point, we can make updates to the library and copy those changes over to our forks, maintaining the improvements over time.

This results in a few significant benefits:

1. Consistent design language

All prototypes maintained perfect consistency with our design system since they used the same underlying components. This allows you to invest once upfront in build high-quality components that are easy to reuse.

2. Easier iteration

When feedback required changes, you can modify specific components without rebuilding entire screens. These component updates could then be used in all future prototypes.

3. Faster onboarding for team members

Getting your team started with AI prototyping can be challenging. By providing a baseline set of components, they can start expressing their ideas right away with visually impressive prototypes.

Although this approach takes a bit more upfront work, I think you’ll find it quickly becomes worth it when prototyping the same application more than once. Give it a try and let me know how it goes!