Stage 6 · Advanced
Shipping apps.
How a thing goes from an idea in your head to a URL that other people use. The pipeline, the two engines that run it, and the command centre it all lands in.
What today looks like
The 60 minutes.
This is the showcase session. You'll watch more than you type today — but you get the keys to the command centre halfway through and you drive it yourself.
PresenterSet the expectation in the first thirty seconds: this is a showcase session with one protected drive-along. Fixed cut order if time slips: first x11, then x19, then x15. Never cut x22 or x23; if you reach x18 with eight minutes left, skip to x21.
Where you got to
You can read a change now.
- You launched Claude Code in a terminal and gave it a real destination.
- You asked for a plan first and approved it before anything happened.
- You read the diff and decided whether the change was right.
- You gave the project instructions in CLAUDE.md.
- You watched the fuel gauge with /context and cleared at task boundaries with /compact.
- You learned the handoff so a long job can continue in a fresh session.
PresenterThree minutes, and ask: “Has anyone opened Claude Code since last time?” The honest answer is usually “once”. A terminal with no destination is a toy. Today it gets a destination.
01 / THE PIPELINE
A change is easy. A thing is a process.
The idea
There is less magic here than you think.
Every app you've ever used is a folder of files that somebody put on a server. That's it. The hard part was never the typing — it's knowing what to build, in what order, and when to stop. That's a process problem, and a process is something you can write down once and reuse.
You've been doing this since stage 1. A skill is a recipe for one job. A pipeline is a recipe for one whole product.
PresenterSay plainly: this shows how it is done; it does not make anyone a software engineer in 60 minutes. The people who get the most out of this stage commission a build rather than write it.
app-builder
Eight stages, and you always know which one you're on.
Say build me an app
Capture the idea → gather requirements → define done → plan the build → build → verify → package and hand over → iterate.
The tracker remembers the position, even three weeks later.
The stages aren't the clever bit. Knowing which one you're on is.
PresenterShow the written position and “Next” line. The room does not need to read the tracker; they need to see that a half-finished build knows where it is.
The one that saves you a month
Nothing gets built until “done” is written down.
The pipeline has one hard stop, and it's early: before any code, you agree what finished looks like — the scope, where the data lives, what it runs on. Everything after that is execution. Everything before it is cheap to change.
A build that skips this doesn't fail at the end. It fails at 80%, when someone says “oh, and it needs to…” — and 80% is the most expensive place to fail.
PresenterCall it what a director already knows: a design freeze under another name.
02 / TWO ENGINES
You are allowed to use more than one.
One turns fog into a spec. The other executes it.
Claude
The ambiguous end: scoping, judgment, writing the spec, work across projects, and anything where the right answer is not obvious yet.
Codex
The well-specified end: one repo, one clear ticket, acceptance criteria written down.
They're not competing. One is thinking while the other is typing.
PresenterSay the cost question out loud: two subscriptions is two subscriptions. It is worth it when there is more well-specified work than hours; not while someone is still learning to write the spec. Quote no monthly figure unless it is on a published price page.
One switch decides who does the work.
Every job carries an engine. Flip it and the same card produces a working prompt for a different assistant, with the project's context and the report-back built in.
The list is the system. The assistants are interchangeable — and that's on purpose, because in two years they will be different assistants.
Learned the expensive way
A thin ticket stalls. Every time.
Hand a well-specified assistant a one-line ticket and it does something plausible and wrong, or it does nothing and you find out on Friday. The ticket is the interface. Where you're going, what file, what “done” looks like — three lines, and the difference between a delivered job and a week of silence.
This is stage 2's gate again, one level down. The whole pipeline is the same rule repeated at different sizes: say what done is, first.
PresenterFirst cut if running long. Keep it if anyone in the room manages people.
03 / THE COMMAND CENTRE
So where does all of this live?
Everything, in one place.
- Overview — where things stand.
- The board — every task, one place.
- Harborview Tower — one assembled project page.
- SnagList — the eight-stage build tracker.
- Portfolio — every app and deck.
- Trace — every work session.
You reviewed a Northgate report back in stage 3. Here's Northgate as a live project.
PresenterThis slide is a live drive. Drive the demo, never the real one. Narrate the job — “it's Monday, what's stalled?” — not the interface. Park feature questions for x22. Until HQ #1657 lands, do not open the Inbox or Workspace menus during the tour until the demo scrub lands.
5 minutes, and you have the keys
Open it yourself.
It's a throwaway copy with made-up projects in it. You cannot break it, and nothing you type in there is real. Break it anyway.
PresenterWalk the room. Do not sit down. Say quietly to individuals: “the version of this for your team would have your projects in it.” Until HQ #1657 lands, do not open the Inbox or Workspace menus.
The point of the last thirteen minutes
Nobody built that by hand.
The command centre was built by the pipeline on slide six, by the two engines on slide ten. It is the thing that runs the business teaching this course.
This is what it looks like when you don't stop at “Claude wrote me a document”.
04 / SHIPPING REALITY
Now the part nobody puts in the demo.
It can even do its own onboarding.
Say make an onboarding video for this app
An intro film — visuals, captions, music, the lot — produced from a config file, then wired into the app for a new user's first login.
You've seen one already. The welcome film at the top of every lesson page came out of exactly this.
PresenterPlay the stage-1 welcome film for two seconds and say “that one”.
The rule that costs the most to learn
“It works on my machine” is not done. Neither is “it deployed”.
Done means live on the real address and checked there — not on a preview link, not on the build that says success. A deploy that nobody opened is a rumour.
Deployed is not delivered. This programme learned that one on itself: a lesson page can be live for two weeks and still never have been seen by a human being.
PresenterTell the true story against this project and against yourself. It buys the room's trust for the honesty slides that follow.
If it's a phone app, read this first
The bit nobody mentions.
A website goes live the day you finish it. A phone app doesn't. Google Play wants twelve testers using it for fourteen continuous days before you're allowed to publish. Apple wants a review, a privacy policy, an account-deletion route. None of it is hard; all of it is calendar.
Start the testing clock on the day you start building, not the day you finish. That one sentence is worth two weeks.
PresenterSecond cut if running long. Skip entirely if nobody has a phone app in mind.
The finish line is not the deploy.
Name a person, not a department.
And who do they tell?
A thing nobody opens is a thing you paid to build twice — once to build it, once in the attention you spent believing you'd shipped something.
Stop building. Start getting users.
PresenterAttribute the final line out loud to Greg Isenberg.
Six stages. That's the ladder.
- Stage 1: ask clearly and get a useful result.
- Stage 2: connect Claude to the work around you.
- Stage 3: chain jobs and write reusable skills.
- Stage 4: stand up tools that stay current.
- Stage 5: plan, read and approve a code change.
- Stage 6: commission a product through a repeatable pipeline.
PresenterLand it as completion, not farewell. The next slide is a beginning.
3 protected minutes
Ask me anything.
What could this do for your work?
PresenterListen for “could it do X for our…”. Answer short, then say “let's take that one after” and mean it.
The first build
What happens next.
What you can do now: you can point Claude at your own work, chain it, build your own skills, stand up something that stays current, read a change, and commission a build.
What you can't do alone yet: the first one. The first build is where every pipeline falls over, and it falls over at “define done”.
The offer: If you want the first one built with you rather than by you — that's a conversation, and it starts here.
Scan to add Stuart to your contacts.
training.stuartdigital.io/card
PresenterDo not improvise a number. If asked: “depends on the shape — let's scope it.” Take the name. Build note: HQ #1079 may later change this slide's body copy only; the layout, position, three-line structure and QR stay fixed.