I carry products end-to-end on my own, and AI is what makes that workable solo. This page breaks the arc into its six stages — Discover, Define, Design, Build, Test and Launch — and walks through the tools and the AI workflow behind each one. It is the long version of how I take a vague idea and get it out the door.
Every project starts close to the user, out in the field, finding the real problem worth solving before a pixel is drawn.
Discovery happens where the work actually is. I run pilot and field interviews on site, observe people doing the job in context rather than describing it from memory, and capture everything into Notion so notes, references and half-formed ideas stay connected and findable. Competitor teardowns sit alongside the raw interview material so I can see the gap clearly.
Claude is my research partner here, plugged straight into where the work lives — email, CRM, analytics and the document library. It pulls context from all of those so research starts with the full picture instead of a blank page. I lean on it hardest for synthesis: clustering interview transcripts, surfacing the patterns I would otherwise miss, and pressure-testing my read of what users are really asking for.
The discipline is to frame everything as a job to be done and resist designing a solution until the problem is genuinely defined. AI-assisted synthesis lets me move from a stack of messy field notes to a sharp problem statement in days, not weeks, so discovery stays fast without going shallow.
Discovery becomes a plan everyone can act on, with the spec drafted, stakeholders aligned and success criteria set before design starts.
This is where I sit in the PM seat. I draft specs and PRDs in Notion, break the work into user stories, and map scope against priority so the team knows what is in, what is out and why. Success metrics get written down at this stage, not retrofitted later, so there is a clear bar to ship against.
Claude does a lot of the heavy PM lifting. I use it to turn discovery findings into structured spec drafts, draft and refine user stories, and stress-test scope decisions by playing devil's advocate against my own prioritisation. It is fast at the structured-writing work that would otherwise eat a week.
The aim is one plan everyone can act on without a meeting to decode it. Aligning stakeholders early — while the spec is still cheap to change — is what keeps the later stages from stalling. A tight definition up front is the cheapest insurance a project ever buys.
This is where I'm deepest, with five years of SaaS and mobile UX behind it — working in systems rather than screens.
Figma is the canvas where most ideas take their first shape. I work in systems, not one-off screens: design systems and tokens, reusable components, and the interaction patterns and flows that hold the product together. Hi-fi prototyping in Figma lets me design every state — loading, empty, error, edge case — and accessibility is built in from the start rather than bolted on.
I use Claude to interrogate my own design decisions — checking flows for the states I have skipped, sanity-checking accessibility, and generating realistic content so mockups never lean on lorem ipsum. It is a sharp second pair of eyes on the parts of a design that are easy to overlook when you have been staring at the file all day.
Designing in systems is the efficiency play: get the components and tokens right once and the design holds up as the product grows. The visual polish comes last, deliberately, so I am not perfecting pixels on a layout that is still moving.
Designs become real here, in code rather than mockups, so ideas can be tested for real instead of imagined.
I build working prototypes by hand in HTML, CSS and JavaScript, and step up to Windsurf for high-fidelity work — data-heavy mockups, real animation, and prototypes tested against actual component libraries. This is where a static design starts behaving like the real product, and where technical spikes settle whether an idea is feasible before anyone commits to it.
AI-paired coding is central to this stage. I work alongside Claude Code and Cursor to get from design to a functional prototype fast — the AI handles the boilerplate and the unfamiliar APIs while I keep my hands on the architecture and the interaction detail. It is what makes building a genuinely clickable prototype solo realistic.
Prototypes are built to answer a specific question, not to be production code, so I keep them lean and scoped to the feasibility check at hand. Building in real code rather than mockups means the next stage tests something honest — how it actually behaves, not how I hoped it would.
Nothing ships on assumptions — the work goes in front of real users and gets pressure-tested against the cases that usually get skipped.
I run usability testing with real users on the working prototype, then pressure-test the build itself: edge cases and empty states, behaviour across devices and screen sizes, and implementation QA against the design intent. Bugs and polish items get tracked in one place so nothing quietly slips through.
I use Claude to generate awkward test scenarios and edge-case data I would not think to try, and to help structure usability sessions and synthesise what comes back from them. It is useful for turning scattered test feedback into a clear, prioritised list of what actually needs fixing.
The empty states, error states and edge cases are exactly the parts that get skipped under deadline pressure, so I test them on purpose. Tight feedback loops — test, fix, test again — catch problems while they are still small and cheap to put right.
The last mile is the part I refuse to drop — driving the polish from the Figma file through to production and out the door.
Launch is about handoff and follow-through. I prepare a clean dev handoff, drive the last-mile polish that separates a good build from a shipped one, and run release QA so what goes live matches what was designed. Once it is out, I stay on the post-launch fixes and watch the success metrics set back in Define to see whether it actually landed.
I use Claude to assemble launch-readiness checklists, write clear handoff and release notes, and sift post-launch analytics for the signal that tells me what to fix or improve next. It keeps the unglamorous end-of-project admin moving so I can stay focused on the polish.
The last mile is where most products lose their shine, so I treat launch readiness as a real stage with its own checklist rather than an afterthought. Measuring impact afterwards closes the loop — it is what turns one shipped project into a sharper starting point for the next.