Loopy

A tool for making and testing product ideas

Loopy started as a set of custom tools that helped me move from a client brief to something people could try. I used them to make prototypes, run user tests, collect qualitative and quantitative feedback, and decide what to change next.

The first version was spread across OpenClaw, Claude Code, and Cursor. I had prompts, plug-ins, and separate AI roles for design, research, evaluation, implementation, and verification. It worked because I knew how to run it, but the method was not visible to anyone else.

Loopy puts that process in one product. The models can change; the briefs, roles, handoffs, checks, and decisions remain.

Keeping the work connected

The client needed to explore ideas without turning each question into a full product cycle. My existing workflow was fast, but the brief, design decisions, critique, prototype, test results, and next iteration could end up scattered across tools and sessions.

I brought those parts into one loop:

1. Write a brief with enough detail to evaluate the result.
2. Generate different approaches to the problem.
3. Choose one and build it.
4. Critique the work before approving it.
5. Test it with people.
6. Use the evidence in the next brief.

Loopy keeps the source brief, design-system version, outputs, reviews, and research attached to each iteration.

Getting three genuinely different directions

One model asked for three concepts often returns the same layout with minor styling changes. In Loopy, each direction gets a separate session and the same pinned brief. Before building, the system finds an important axis in the problem and places each direction at a different point on it. If two results solve the problem in the same way, one is generated again.

A survey brief, for example, produced a one-question-at-a-time flow, a scrolling conversation that kept earlier answers visible, and a fixed workspace. Those were different interaction models, not color variations.

Separate roles for making and critique

After I choose a direction, a senior designer role builds it and a principal designer role reviews it. The first role must find a workable answer. The second checks the brief, design system, accessibility, craft, and whether the concept is still distinct from the alternatives.

Some checks are deterministic; others need visual judgment. I decide whether the work moves forward.

Review and routing

A direction can be approved, steered, or rejected. Approve makes it available for testing. Steer adds written direction and starts another iteration. Reject closes it.

The scorecard records which brief and design-system version the AI roles used, what failed, what changed, and why the work continued. The score is there to support a decision, not replace one.

Testing the prototype

The first version stopped when I approved a design. Client work showed that approval was too early: the prototype existed to answer a question.

An approved iteration can now become a stable test link. I can run a qualitative usability study, collect structured feedback, or combine methods. For external tests, Loopy publishes a study bundle to Netlify, adds the feedback mechanism, syncs responses back into the project, and closes the deployment when the study ends.

I tested the full path with a client prototype: publish it, collect feedback, return the evidence to Loopy, and use the findings in the next brief.

Building Loopy with AI

I set the product direction, designed the system, wrote and tuned the AI roles, made the interface decisions, and built the software. AI helped with research, writing, coding, critique, and verification, and let me work across a larger scope than I could have handled alone.

I still decide how each role is set up, what context it receives, what it may change, and which gates require a person.

From Plumbline to Loopy

The project was originally called Plumbline because I was focused on design-system drift and whether an output stayed true to its source. As the work developed, the repeated cycle of making, reviewing, and testing became more important than the final compliance check. I renamed it Loopy.

Where it is now

The beta supports structured briefs, project context, three separately generated directions, concept selection, designer and critic roles, scorecards, approve/steer/reject routing, test publishing, feedback collection, outcome evaluation, and a human-approved next brief.

It also has approval-gated signup and organization-level separation for projects, studies, files, and artifacts. Those controls matter because the system can use credentials and run jobs on a user's behalf.

Next I am testing it across more client work: whether the scores remain useful, whether the research setup produces good evidence, and whether each iteration improves the work.

My role

Loopy is my product. I lead the strategy, design, research approach, AI workflow, implementation, and deployment.

Try Loopy

Visit loopy.design