Adam Green

Reforge Build · 2025 to 2026

From idea to a paid AI prototyping product in six months

Reforge Build helped product managers turn ideas for existing products into interactive prototypes. I defined the product, designed and coded its first interface, and led product and design through launch.

  • 6 monthsfrom kickoff to a paid product
  • 1 → 5engineers as the Build team grew
  • 1,000+Reforge Build users in four months
My work
Product strategy, product design and design engineering
Team
Started with one engineer. Grew to five engineers, including a design engineer, plus a product designer.
Product status
Launched November 2025
Explore in Figma

Introducing Reforge Build

Problem: Product teams don’t want to prototype from scratch

Product teams already had customer feedback, a working product and ideas about what to improve. Existing prototyping tools made it easy to start from scratch, but offered less support for building on a team’s existing work. As AI made software easier to produce, our bet was that choosing the right solution would matter more.

I shaped Reforge Build’s strategy around helping teams make that choice: bring in product context, explore alternatives and gather feedback before committing to implementation. The goal was to make those steps faster, with prototypes that supported learning and decision-making rather than promising production-ready software.

Build in the solution-development loop · August strategy

Build focuses on exploring and testing solutions. Customer insight comes from earlier in the process; implementation follows once a direction is chosen.

Shaping the roadmap through continuous user feedback

I kept talking with product managers as we built, using their workflows and feedback to decide where Build needed to go beyond a blank prompt. Those conversations guided the initial scope and the priorities I set as the product developed.

Insight

Prototyping started with an existing product and a specific change.

PMs needed to explore a change while preserving the product around it.

Interview evidence

“really good at like starting from zero, less good at iterating on an existing code base.”

Product leader, on using AI to prototype

What I prioritized

Import the existing product, then capture its flows

I prioritized screenshot and Figma imports, then a browser extension that captured the product’s page structure (DOM). We expanded capture from individual screens to connected flows.

Insight

Seeing alternatives helped PMs decide which direction to pursue.

Comparing versions helped PMs explain why a direction did or didn’t make sense.

Interview evidence

“I often will also do a different one with very similar prompts to see what comes out.”

Senior product manager, on exploring options

What I prioritized

Explore alternatives at prototype and component level

I prioritized whole-prototype variants to compare directions, then component variants for decisions within a screen. The team released component variants for refining elements such as cards and pricing components.

Insight

The audience determined how finished a prototype needed to look.

Rough concepts kept early feedback open. Other stakeholders needed more realistic detail.

Interview evidence

“It's just to do it faster, to get early feedback”

Senior product manager, on reviewing rough concepts

What I prioritized

Offer wireframes alongside more detailed prototypes

I prioritized a wireframe option and experiments with Quick Build and Plan modes, so people could choose the depth they needed. Inferring that choice automatically remained a longer-term goal.

I scoped the first version around bringing in product context, generating options and sharing prototypes for feedback. Capture, variants and fidelity controls developed from those priorities over time.

Turning a working prototype into an interface for PMs

One engineer and I started by building a working prototype, initially with our own coding agent. I coded and refined the frontend while he built much of the underlying functionality and contributed interface choices as we went. Our first goal was to get from a prompt to a generated prototype. We later adopted Claude Code as the coding agent.

Local prototype

Getting generation working end to end

The first local interface put the conversation beside its generated output. It gave us a working foundation for deciding which controls a product manager would need.

MVP for user testing

Making chat and visual editing the main ways to work

We expected most PMs to spend little time in code, so we treated it as a secondary option alongside chat and visual editing. In this MVP interface, Code was an alternative tab in the left panel. The navigation established three levels from the outset: a workspace containing projects, each with multiple prototypes. Projects would hold shared context and support collaboration.

Around the beta

Moving code beside the preview for quick changes

As we refined the interface, we found that people still wanted to make quick code changes, such as editing text. Moving Code to the right kept those changes close to the preview and gave code export a more natural home. Chat and Edit stayed on the left, with product files and clarifying questions in the conversation.

Toward the paid product

Revealing editing tools when people need them

I kept reducing the visible controls and giving the prototype more room. We moved toward showing editing tools when someone selected an element, instead of keeping a separate Edit menu visible. This later interface shows the simpler frame: no Chat or Edit tabs, a compact project header, and preview and code controls together above the canvas.

An architecture that lets teams explore without starting over

I translated what we were learning from PMs into requirements for reusing context, brainstorming variants and collaborating on each direction. I led the architectural decisions with engineering, defining what would be shared across prototypes and what each prototype needed to keep independently.

Requirement 01

Reuse context across prototypes

Keep workspace and project context available as people explore new ideas, without adding the same files and instructions again.

Requirement 02

Explore and refine variants independently

Let people brainstorm directions, edit each independently and bring collaborators in for feedback.

Architectural solution

Share context while keeping each direction independent

I worked with engineering to organize reusable context at workspace and project levels, while giving each prototype its own conversation and history. That let variants start from the same material and develop independently.

Workspace

The company’s design system and shared instructions.

Carry across projects
Project

The problem, requirements and source files for the work.

Reuse across prototype options
Prototype

One direction, with its own conversation and history.

Build on workspace + project context

Build used file summaries to select relevant project material for a request and combined it with company instructions, rather than sending the entire project library with every prompt.

Store each direction as a separate prototype

Whole-prototype variants live as separate prototypes within a project, so editing one does not overwrite another. Duplicating an existing version starts another prototype and carries over the conversation, letting someone explore from that point.

Keep component variants inside a prototype

Options for a button, card or other part of a screen belong within the prototype being refined. Choosing a component variant updates that part of the screen without creating a separate prototype for every small change.

Attach feedback to the version reviewed

Each prototype keeps a history of its versions, with comments attached to the design someone saw. Restoring an earlier version creates a new one, preserving the changes made since. The share link opens the latest version while earlier feedback stays tied to its original version.

The model I developed with engineering maps these decisions: separate prototype variants within a project, component variants within a prototype, and comments attached to specific versions. It also defines how duplication and restoring earlier work affect that history.

Interface refinements in code

Alongside product and design, I wrote frontend code for Reforge Build. I refined shared inputs and controls, and used working code to explore changes to the builder’s layout. Some changes went directly through review and into the product; others were carried forward with engineering.

01

Refining reusable inputs and controls

Merged · PRs #226 and #427

I refined the shared prompt input used on the home and project pages, and the composer used in the builder. Text, attachments and actions each have their own space, so longer prompts scroll without moving the controls. I also replaced one-off button styling with the global Button component, keeping sizing and mode states consistent.

Builder composer
Interactive reconstruction

Try a long prompt, add a sample attachment or change modes. The controls keep their own space.

Sample content. AI, file uploads and Figma are not connected.

Ask Build to change your prototype.
brief.md
02

Switching between preview and code

Initial code #414 · Shipped with engineering #578

I moved code editing into the preview panel so the conversation could stay visible. Files gained their own column, and editing actions moved into the toolbar. Engineering carried the work into the product through a separate branch. The demo follows that version’s paired Preview/Code switch, file selection and Save/Discard states.

Code in the builder
Interactive reconstruction

Open Code, edit a file, then save or restore a version in chat.

Sample content. Versions stay in this demo; the preview is static and code does not run.

Preview ready.

Chat
Create a homepage for Twin Maple Farms.
Here’s a starting point for the farm’s homepage.
Ask Build to...
/

From zero to a paid product in six months

In six months, Reforge Build went from an initial idea to a paid prototyping product for individuals and teams, becoming a core part of Reforge’s product offering.

We started with one engineer and grew to five engineers, including a design engineer, plus a product designer. I owned product priorities, research and design, worked with engineering on the architecture, and contributed frontend code.

Delivery timeline

  1. July 2025

    Product kickoff

    Product scope and a working prototype. I coded the frontend alongside one engineer building much of the underlying functionality, initially with our own coding agent.

  2. August 2025

    Waitlist and closed beta

    Generation, product context, sharing and feedback in users’ hands.

  3. October 7, 2025

    Open beta and individual billing

    Open access, Free and Individual plans, and usage credits.

  4. November 12, 2025

    Public launch

    The wider launch followed beta access and the first billing release.

  5. December 2025

    Team infrastructure

    Workspace scoping, organization switching and shared-resource foundations.

  6. January 2026

    Teams and team billing

    Shared projects, prototypes and context, with pooled credits and team subscriptions.

Team-wide repository activity

Pull requests merged into main each month · June 2025 to February 2026

2025

  • Jun48
  • Jul78
  • Aug137
  • Sep88
  • Oct175
  • Nov163
  • Dec100

2026

  • Jan144
  • Feb258

Our working cycle

We kept a project backlog of feature summaries, each framed around what a user should be able to do. Clear outcomes and narrow scope gave engineers room to decide how to deliver them.

Sprint length
1–2 weeks
Roadmap horizon
3–4 weeks
Reprioritization
Every Monday

Claude and Codex throughout the loop

I used AI to synthesize research, shape feature briefs and work in code. I kept feeding project material into a local wiki so I could reuse research and decisions as context for the next task.

  1. Research and prioritize

    I interviewed users and used Granola’s MCP connection to bring those conversations into Claude for synthesis. I kept the findings in Notion and used them to update our feature backlog.

    Tools
    • Granola
    • Notion

  2. Scope around a user outcome

    Each feature brief named the user outcome, rough requirements and what was out of scope. I linked the Notion one-pager and Figma mocks or prototype in a Linear project. Engineers chose the implementation and ticket breakdown.

    Tools
    • Notion
    • Linear
    • Figma

  3. Build and refine on the branch

    Engineers built on GitHub branches. We reviewed the working feature in Vercel previews, and I used AI coding tools to make frontend refinements on the same branch. Design feedback could become a code change in the same review cycle.

    Tools
    • GitHub
    • Vercel

  4. Release and learn

    We shipped small feature releases in one- to two-week sprints, then brought feedback and fresh user conversations into the backlog. Each person had two or three core weekly goals, making changes in priority an explicit tradeoff.

Back to priorities every Monday. We revisited the next three to four weeks based on what we’d learned.

A paid product in six months, then the move to Miro

By November 2025, Build had paying users. We continued improving generation and editing, then added team access and pricing.

  • 1,000+Reforge Build users in four months
  • 1,191pull requests merged by the team, Jun 2025 to Feb 2026

After Miro acquired Reforge in March 2026, Build wound down. I shared our learnings with Miro’s prototyping team. After other work at Miro, I became the lead for Miro Prototyping.

What I’d do differently

Getting people to try Build was easier than keeping them. Output quality, broken workflows and low switching costs made repeat use harder. I still question whether our initial focus on PMs was broad enough.

From idea to a paid AI prototyping product in six months | Adam Green