How to Build an App With Claude, Start to Finish

Ellie at Willa, Editorial lead, Willa · Published August 13, 2026 · Updated August 25, 2026

Most "build an app with AI" tutorials skip straight to the magic moment where code appears on screen. Willa's four-part live series, the Real Claude Build Workflow, did the opposite. Over four weekly sessions, AI consultant Kimberley Bueno walked members through the entire journey using a different Claude tool at each stage. Kimberley brings about ten years of fintech and product experience, shipped apps at Coinbase and MoonPay, and recently got her own to-do app, Nudger, approved for the Google Play Store. To make it concrete, she built a brand-new app live across the sessions: a coffee-shop finder for remote workers she dreamed up an hour before class. This guide distills all four sessions into one workflow you can follow.

What is the right order of Claude tools for building an app?

Kimberley's workflow moves through four Claude surfaces in a deliberate order:

1. Claude Chat (session one: idea). Talk through your problem and solution, ideally on your phone, inside a Claude project named after your app.
2. Claude Cowork (session two: plan to wireframe). Have Chat package your idea into a product doc, then ask Cowork for gray, low-fidelity wireframes and an end-to-end user journey.
3. Claude Design (session three: prototype). Pass a design spec from Cowork to Claude Design for high-fidelity screens, then a clickable prototype.
4. Claude Code (session four: build and launch). Ask Design for a technical spec, hand it to Claude Code, and let it build the actual app.

The glue holding the workflow together is one repeated move: at the end of each stage, ask Claude to package up the work for the next tool.

Why not just jump straight to code? Because each stage is the cheapest place to fix a certain kind of mistake. Fixing idea, journey, and visuals all inside Claude Code burns tokens and patience. "It's really important to have a good design, it's really important to have a project plan," Kimberley told the group in the final session. "If you know exactly what you want to do, it's going to be a lot easier to use Claude Code."

How do I come up with an app idea worth building?

The first session was pure product management, and its core lesson applies before you open any tool. People assume lots of features make a good app, but Kimberley sees the opposite pattern across successful products: "The features are kind of bells and whistles, but the problem is everything."

Her test is blunt: if you can't state the problem in one sentence without naming your app, you don't really have a problem, just a feature idea. Calendly, her go-to example, isn't "a scheduling app"; it solves "professionals waste time and look unpolished trading emails just to find one meeting slot."

Her ideation process has four stages: define the problem, research the market and competitors, brainstorm with Claude, and prioritize features. A few specifics from the session:

• Frame the problem in three parts: who you're targeting, what the pain point is, and what workaround people currently use.
• Come to Claude with an idea, not for one. If Claude generates the idea, you won't feel connected enough to the problem to push through building it.
• Give Claude your whole day as context. When one member pitched a cycle-synced fitness idea, Kimberley coached her to narrate her actual Sunday planning routine ("at 8 o'clock I wake up, at 9 AM I open my planner") so Claude understands exactly when and how the problem shows up.
• Create a Claude project first and name it after your app, so everything transfers cleanly when you move to Cowork.
• Resist scope creep. "People know Duolingo because of the leaderboard, but they're actually going to Duolingo because they want to learn a new language," she said. Nail one core feature, your P0, before adding anything.

Expect to go "on a loop and not a line" at this stage: the problem and solution will shift as you talk it out. That's fine. The goal is a problem and solution defined clearly enough that you never have to return to the whiteboard mid-build.

How do I map my user journey and wireframes in Claude Cowork?

Session two turned the idea into screens. Kimberley describes Cowork as "an extra pair of hands": Claude doing work on your computer on your behalf. Her handoff move: in Claude Chat, ask "can you package this up so I can pass this to Cowork, to start building the first draft of wireframes for the screens?" Hers produced a README, screen specs, a design brief, and a product doc. Then, in a Cowork session, she pasted the docs with a prompt this simple: "Please help me design some high-level wireframes and map out the user journey for this app."

Cowork asks clarifying questions before it builds. Kimberley's answers are instructive: static wireframe images rather than an interactive HTML prototype (save that for Design), and "P0 core loop only," meaning just the priority-zero features, your product roadmap's first line.

When the gray wireframes arrive, the real work is critique. Go through every screen and be nitpicky, but batch your feedback, because every prompt costs credits. Her example note: "I want the user to first see a map when they open up the app."

She frames a strong user journey as a loop of three parts: onboarding (get people in with as little friction as possible; people are lazy about forms), the main feature (the solution to your problem), and retention, which in her view mostly takes care of itself: "The only reason most people come back to an app is because you're solving a pain point consistently and consistently well."

One more decision matters before you wireframe anything: does your idea even need to be an app? Kimberley's rule of thumb is that apps are for products other people will use, since they come with app-store approvals, overhead, and AI-credit costs. If the tool is just for your own workflow, an agent or automation is usually the better shape, and you can learn to build your first AI agent instead. As Allison, Willa's founder, pointed out, it cuts both ways: an agent can be a great way to start what later becomes an app, since you can test and train it in real life first.

How do I create a clickable prototype in Claude Design?

Session three moved to Claude Design (claude.ai/design, available on paid plans), a competitor to Figma or Canva that can produce app screens, decks, brand guidelines, and more. The handoff repeats the pattern: ask Cowork for a design spec collating your user journey and screens, then paste it into Claude Design with a short instruction to build high-quality screens.

Key practices from her live build:

• Choose your visual direction deliberately. Design proposed three styled options and even recommended one. "You don't always have to go with the recommendation," she noted. "They're not the expert. You are the person who is building this."
• Screens first, clickable prototype second. Jumping straight to an interactive prototype means burning far more credits on every revision. Only after approving the screens did she prompt: "This looks great. Can you turn this into a clickable prototype that I can present to investors?"
• Keep each tool in its lane. Make visual refinements in Design, but take user-journey changes back to Cowork. Big product changes inside Design get messy and expensive; she's hit her usage cap on a Max subscription doing exactly that.
• Own your colors. Don't let Claude default to its favorite palette. Decide what you want users to feel, then ask Claude Chat for ten palette options with that context, or upload screenshots of apps whose look you love.
• Audit against apps you already use. Her recurring exercise: open a favorite app and narrate what you actually do. She Googles "coffee near me," so her app's first screen became a map. Ask yourself why you prefer Pinterest over Instagram, and steal the answers.

How do you know you're done? When the screens match the exact user journey you defined and the visuals feel right, package it up for code. In Cowork and Design "you get to see the magic happening in front of your eyes," she noted; in Claude Code you won't, so get the design as close to final as possible first.

How do I build and launch my app with Claude Code?

The final session demystified the scariest step. Do you ever have to touch code yourself? "You don't have to know any code at all," Kimberley answered when Allison asked. "You can think of Claude Code as our hands. We're basically the person telling Claude Code what to do."

Her workflow:

1. Ask Claude Design for a technical spec: "Please write me a technical spec that includes the design and capabilities of this app, that I can pass over to Claude Code." Download the files it packages.
2. In the Claude Code desktop app, create a fresh folder for the project so every file Claude writes stays contained, which matters later for revisions or for having another tool review the code.
3. Drop in the spec and set the ground rules: she tells Claude to have her review everything before publishing or moving forward, and to "propose your development plan first, before executing."
4. Approve permissions one by one. Claude Code asks constantly, and while you can auto-approve, she doesn't: each request is a chance to check the work against the plan. If a notification is confusing, paste it into Claude Chat and ask it to explain for a non-technical person.
5. Start with the core screen loop, not every edge case, and preview the result at the localhost URL (visible only on your own computer).

For launching, her strong recommendation is web first, native later. A web app needs only a domain, hosting, and your Claude subscription. She uses GoDaddy, SiteGround, Vercel, and GitHub, plus Supabase when a database is needed. "I've built websites for clients within three days. End-to-end, full-on, shipped," she said. App stores are a bigger commitment: Google Play and Apple both charge annual fees, require business registration, and run approval processes (hers took about two and a half weeks), so treat a web launch as your beta test for whether people actually want the thing.

One budget warning: Claude Code is token-hungry. That's the practical payoff of the whole four-stage workflow: arrive with design and plan finished, so Code only builds.

Key takeaways

• Build in stages across Claude's tools (Chat for the idea, Cowork for wireframes and user journey, Design for the prototype, Code for the build) and end each stage by asking Claude to package a spec for the next tool.
• The problem is everything: if you can't state it in one sentence without naming your app, you have a feature idea, not a product.
• Prioritize ruthlessly. Ship your P0 core loop first; retention follows from solving one pain point consistently well.
• Fix things in the cheapest tool: journey changes in Cowork, visual changes in Design. Claude Code (and prototype revisions in Design) consume the most credits.
• In Claude Code, you direct rather than program: require a proposed plan first, review before anything publishes, and launch as a web app before attempting the app stores.

If Claude Code sounded like the intimidating part, start with the Claude Code starter pack for building your first website; it pairs well with the launch steps above.

Join us for the next one

This guide came from four live Willa events, where members workshopped their real app ideas with Kimberley on screen. There's already demand for a Claude Code deep-dive follow-up. Willa hosts expert-led sessions like this almost every week for women building careers with AI. See what's coming up on our events page, or become a member and build alongside a community that's figuring this out together, in real time.

• Claude
• app development
• no-code
• prototyping
• product management
• vibe coding

Join Willa, the community where women learn AI together.

All posts