Ship Your First App With Muse

Every Friday morning I run the same session. One idea in, one working app out, ninety minutes on the clock. The apps are small: a reading tracker for my book club, a quote calculator for a friend’s catering side business, a dashboard that turns my weekly numbers into something I can glance at over coffee. Nothing that handles money, nothing that holds anyone’s private data, nothing the world depends on. That boundary is the whole reason the session works, and we will get to why.

I call the session the Friday Forge: a standing arrangement with my Muse (a brief template, a build loop, and a ship checklist), run the same way every time until the mechanics disappear and only the building is left. This lesson is the Forge, end to end: the two routes to a working app, the loop that gets it right, the definition of v1 done, and the honest accounting of where this kind of building stops being safe.

The Two Routes

Muse builds apps two ways, and they serve different people. Pick yours before you start, because switching mid-build costs you the context you already paid for.

Route one is the artifact route, inside the Muse app or the web chat. You describe the app in plain language, Muse builds it, and you test it right there in the conversation. Upload a file or ask Muse to create one, and it can read, summarize, edit, or generate artifacts; finished artifacts are saved to your workspace in the Library tab and shared in the conversation. Your loop is pure conversation. Muse asks clarifying questions, gets to work, and you review what it does and ask for changes. This is where personal tools, demos, and prototypes live. Muse builds personal tools like trackers, dashboards, and small sites; serious software work belongs to Muse Code or the Muse Spark API.

Route two is Muse Code, Meta’s terminal coding agent for people who can read what gets written. It installs with one command (curl -fsSL https://dev.meta.ai/install.sh | bash), signs in with a Meta developer account, and takes plain-language work orders like muse "migrate auth to passkeys". Background agents work in isolated git worktrees, every tool call lands in a full event log you can audit and replay, and nothing merges until you review it. It left beta on August 31, 2026, with monthly plans from $5 to $200 or pay-per-token API billing. If you can read code, this route gives you something the artifact route cannot: a real repo, a real diff, and the ability to maintain the thing next year.

The Forge below runs on route one, because that is the route most readers can run this Friday. If you take route two, the task-brief lesson still applies to how you write the work order, and the loop below still applies to how you test. Only the venue changes.

The Setup: The Friday Forge

The Friday Forge has three parts and none of them are optional: a brief template, a standing memory line, and a session rule.

The brief template is five lines, and you fill it in before the session starts:

1. The one job: the single thing the app must do, in one sentence.
2. The user: who it is for, including their patience level.
3. The screens or states: what the user sees, in order, no more than three.
4. The data rule: local only, no accounts, no real names, no email addresses.
5. The phone rule: it has to work on a phone screen, because that is where it will get opened.

Keep the filled-in brief in Muse’s standing memory once a project is underway, so every follow-up starts from your product’s rules instead of the model’s defaults. The memory lesson covers how to store and audit that. The five-line brief itself is a special case of the general briefing discipline in the task-brief lesson.

The session rule is the clock: ninety minutes, one idea, one app. The clock is doing real work. It forces the brief to be small enough to finish and the app to be small enough to test. An app that needs more than ninety minutes is two apps wearing a trench coat, and it goes back into the idea list split in two.

Run each app in its own side chat. Side chats keep topics organized without cluttering the main chat, and a build accumulates dozens of messages (screenshots, fix rounds, test notes) that you never want mixed into your Tuesday planning thread.

The Loop: Screenshot, Describe, Fix

The first build is never the app. It is the starting position. What turns it into the app is the loop, and the loop has four steps.

First, open what Muse built and use it like a stranger would. Not like the person who wrote the brief, like the person the brief was written for. Click everything. Type the wrong thing into every field. Leave fields empty. This is the most valuable ten minutes of the session, and most people skip it because the thing already looks done.

Second, screenshot everything wrong. Not a description of what’s wrong: the actual screenshot, pasted into the chat. A screenshot carries the state you cannot describe: the spacing, the dead button, the thing that renders fine on your description but wrong on screen.

Third, paste the fixes back as a numbered list in plain language, with one rule attached: fix only what I listed. Do not redesign anything else this round. Scoped fix rounds are what keep the loop from spiraling. Use follow-ups instead of starting over, and say exactly what format and outcome you want.

Fourth, repeat until the ship checklist passes. Two or three rounds is normal. Five means the brief was too big; shrink the app, not your standards.

The Copy-Paste Prompts

Prompt 1: The Build Brief

Build me a working app from this brief. The one job: [one sentence]. The user: [who, and their patience level]. Screens, in order: [up to three]. Data rule: store everything locally in the app, no accounts, no real names, no email addresses. Phone rule: it must work on a phone screen. Ask me up to three clarifying questions if anything is ambiguous, then build the first working version as an artifact I can test here in chat. When it is ready, walk me through how to use it in three sentences or fewer.

Prompt 2: The Screenshot Fix Round

Run this with the screenshot attached, once per round:

Attached is a screenshot of the app you built. These are wrong: 1) [describe exactly what is wrong], 2) [describe exactly what is wrong], 3) [describe exactly what is wrong]. Fix all three and tell me, in one line each, what you changed. Change nothing else in this round.

Prompt 3: The V1 Ship Test

Here is my v1 checklist: the one job works end to end; a first-time user can complete it without me explaining anything; empty inputs and wrong inputs fail gracefully instead of breaking; nothing leaves the app and nothing is stored that identifies anyone. Test the app against every item like a first-time user and report pass or fail per item, with the exact input you used for each test. Do not mark anything done that you did not actually test.

What Done Looks Like for V1

V1 is the smallest version a stranger can use without you in the room, not the app you imagined, and it has exactly four properties: one job that works end to end, usability without narration, graceful failure on dumb input, and no real user data anywhere in it. If it needs your explanation, it is a demo. If it holds someone’s email address, it is a liability wearing a demo’s clothes.

When the route produced real code (the Muse Code route, or an artifact you plan to keep and extend), read the diff before you call it done, or have someone who can read it do that for you. The engineers lesson is the full discipline: review, repo hygiene, and the nightly audit. The Forge’s version fits in one line: never ship code nobody has read.

Academy Muse for Engineers: Code Review, Repo Hygiene, and the Nightly Audit

What Can Go Wrong: The Invisible Foundation

The failure mode is the one you cannot see. The research on this is now past anecdote. Security firm Escape scanned more than 5,600 live vibe-coded apps and found over 2,000 vulnerabilities, more than 400 exposed secrets, and 175 cases of exposed personal data. Veracode tested AI-generated code samples and found 45% failed its security tests. University of Virginia researchers tested coding agents on 200 real-world feature requests: agents passed the functional tests 61% of the time, but only 10.5% of those passing solutions were actually secure. Tenzai’s December 2025 assessment of five major coding tools found 69 vulnerabilities across 15 test apps, the most serious in API authorization logic and business logic. And the fix-it loop itself is part of the problem: research summaries of these studies note that each revision round adds new flaws, because prompts that push for feature completion keep producing fresh vulnerabilities. Andrej Karpathy coined “vibe coding” in February 2025 to describe building without reading the code. The data since says the part you skip, reading it, was load-bearing.

The fix is the scope rule, and it is non-negotiable: prototypes, demos, and personal tools are the safe zone. Anything that touches real user data, logins, or money gets an engineer’s eyes on the code before it ships, full stop. The rule comes from the failure-modes lesson: know which failure you cannot afford, and put the guardrail ahead of it.

That is no reason to stop building. Know which game you are playing. The Forge builds real, working apps in ninety minutes, and that is genuinely new. It does not build production software, and pretending otherwise is how the invisible foundation cracks.

Ship Friday. Read the code when it matters. And when the Forge produces a workflow worth keeping, package it the way the setup lesson describes, so the next idea starts from a template instead of a blank page.