My Process

How I approach building products has changed significantly. This page reflects where my thinking is today — using AI to move from concept to working application in days, not weeks or months. How I used to work can be found on the "My Old Process" tab and captures the traditional process I still draw from when the situation calls for it.

Design Process

Full-stack product creation through Agent management and experience based judgment

The way I approach designing products has changed fundamentally. The old model — research, define, design in Figma, prototype, hand off, build — made sense when each phase was expensive and time-consuming. That process is no longer efficient. With AI as a core collaborator, I can get from a raw concept to a working, testable application in 1–2 days. That changes everything about how you solve problems and validate ideas.

I spend my time providing direction, critiquing work, and making decisions — and limit hands-on execution of the work itself. The process is more iterative, more fluid, and more focused on learning through doing than on upfront planning.

01. Start With AI, Not a Brief

Before writing a single line of code or opening a design tool, I have a conversation with AI about the problem space. If I have research or other context, I share that with AI then I ask it to help me think through:

  • What problems do users in this domain typically run into?
  • What are the core use cases for this type of application?
  • What edge cases or secondary flows are likely to emerge?
  • What are the most common mistakes made when building something like this?
  • What already exists in the market, and where are the gaps?

This isn't just a shortcut — it's a genuine upgrade to the discovery process. AI has been trained on an enormous breadth of product discussions, research, and domain knowledge. Using it as a thinking partner surfaces considerations that would normally take days of research or stakeholder interviews to uncover. It gets me oriented in the problem space fast, with enough grounding to make informed decisions about what to build first.

02. Scaffold a Working Application in Hours

I've built a custom CLI scaffolding tool — itself built with AI — that takes a concept and spins up a fully structured, working application. It doesn't generate throwaway boilerplate. It produces an application with real features baked in:

  • Authentication flows
  • Navigation structure
  • Design system integration (component libraries, theming)
  • Optional posts, calendar, feedback collection, and AI assist

Once the scaffold is in place, I prompt AI to begin developing features. I describe what I want, it builds it, I test it, I react to it, and we iterate. The back-and-forth is fast because we're working in real code with a real running application — not a prototype that simulates behavior.

03. Multi-Agent Product Engineering

For more complex applications, I work with multiple AI agents simultaneously, each focused on a different part of the codebase. One might be working on the data layer while another is handling UI components or an API integration.

My role in this process is agent manager and taste-maker. I'm orchestrating where effort goes, deciding what to build next, reviewing what comes back, and course-correcting when things drift. I'm not just a prompt writer — I'm making product and design decisions continuously, keeping the overall vision coherent while agents handle execution in parallel.

This is a meaningful shift in what "designing" a product looks like. The speed of execution means more of my energy goes toward judgment — deciding what's right, what works, what needs to change — than toward production.

04. Wireframes, Low-Fidelity Mockups, and Figma Are Optional - and Often Skipped Entirely

Design fidelity is not critical when you're building to validate. Design artifacts exist to explore ideas, reduce ambiguity, drive consensus and more. But when the artifact is a working application, the gaps change. You can directly debate the experience - or just test it and see what happens.

I can make design changes directly in code just as quickly as I can in Figma — especially when I'm working with a design component library. Spacing, layout, color, hierarchy: these are fast to adjust in a component-driven codebase. The permanent, invisible tradeoff with Figma is that you're maintaining two sources of truth. I'd rather just have one.

Figma is still the right tool in certain contexts — presenting visual work to stakeholders who need to annotate it, or doing detailed design exploration before development begins. But as a default step in every workflow, I think it's become less effective for the kind of work I do.

05. Test It in 1–2 Days, Not Weeks

The premise behind this entire approach is simple: get something real in front of you — and potentially in front of users — within a day or two.

That kind of speed changes how you think about a concept. You stop over-engineering the idea in your head and start reacting to something tangible. You discover what you like, what doesn't work, what the experience actually feels like when you use it. You can put it in front of a real user and get genuine feedback before you've over-committed to anything.

This is faster than any prototype I've ever designed in Figma, and it's more honest — because it's the actual thing, not a simulation of it.

06. Know When to Throw It Away

One of the most important things I've learned: sometimes you have to throw the code away.

When an application grows quickly and the architecture wasn't set up for where it's now headed, AI agents start to struggle. Future requests get tangled in existing complexity. The responses get less reliable. Small changes have unintended side effects. When that happens, it's often faster to start over with a clearer plan than to keep patching something that's fighting you.

This isn't a failure — it's the process working as intended. The first version wasn't wasted; it was a learning exercise that cost you two days, not two months. Starting fresh with better knowledge of what you're actually building usually results in a cleaner, faster second version anyway.

The ability to throw it away without guilt is one of the most underrated advantages of this approach.

Learn More

I write about this process in detail on my AI Projects page — covering specific techniques, tools, workflows, and real examples of applying this approach to product development.

If you're a hiring manager or someone looking for a collaborator who is actively using AI for serious product development, that's the best place to start.