Ship It¶
From Verified to Live¶
You've built features, verified them against acceptance criteria, and now have automated tests that check themselves. There's one step left: put it in front of real users.
Think back to the Explore step — the very beginning of your workflow. You started by understanding who you're building for: backcountry skiers who need to report conditions, forecasters who review those reports each morning to produce danger ratings. You made assumptions about what they need, how they'd interact with the platform, and what would make a real difference in their workflow. Those assumptions are baked into every user story you wrote and every acceptance criterion you defined.
Here's the thing: your tests verify that the code works as specified — but they can't tell you whether the specification itself was right. Does the observation form actually make it easier for a skier to report what they saw? Does the feed layout help a forecaster find the critical observations quickly? You won't know until real people use it.
Every product is built on assumptions. Deployment is how you start validating them. Until your application is in front of real users, you're guessing — no matter how good your tests are.
The Full Pipeline¶
Here's what the complete workflow looks like, from idea to live application:
- Explore — understand who you're building for and what they need
- Plan — write user stories with acceptance criteria (your delegation contract)
- Implement — hand the story to AI and let it build
- Verify — automated tests pass + visual verification confirms the experience
- Ship — deploy to a live URL
The first four steps are the Explore → Plan → Implement → Verify workflow from Lift 1, with Lift 3's automated tests now handling the Verify step. Deployment is the natural conclusion: once tests confirm the work is verified, ship it.
Tests gate deployment. If your tests pass, you have evidence that the application works as specified. If they fail, something needs to be fixed before it goes live. This isn't about being cautious — it's about being confident. You ship because the tests give you reason to.
The ideal: one command that runs everything — all your quality checks, tests, and the build. A single signal: pass or fail, no partial credit. When that command passes, you're clear to ship. When it fails, you fix before you ship. It doesn't matter who wrote the code — you, AI, or a teammate. The gate is the same.
But notice that the pipeline isn't a straight line — it's a loop. Shipping connects back to Explore. Real users generate real feedback: they use features you didn't expect, ignore features you thought were essential, and ask for things you didn't anticipate. That feedback becomes the most valuable input to your next round of Explore. You built what you thought users needed. Now you find out if you were right — and what to build next.
Deployment in Your Environment¶
Your Coder workspace comes with a deployment pipeline already configured. You don't need to set up servers, configure infrastructure, or understand cloud architecture. The hard part is already done.
Deploying is as simple as asking your AI coding assistant:
Deploy the application.
Claude Code will use the pre-configured deployment pipeline in your Coder workspace. It handles the build, runs your tests, and pushes to the live URL.
Codex will trigger the deployment pipeline, following the same build → test → deploy sequence.
pi.dev will run the deployment workflow configured in your workspace.
When deployment completes, you'll get a live URL. Open it in your browser. This is your observation network — live, accessible, built by your team with AI.
Team Activity: Deploy Your Observation Network¶
Format: Mob Session Time: ~3 minutes Setup: One person drives, everyone else navigates. Use the same workspace where you've been building.
Step 1: Make sure your tests pass. Ask your AI coding assistant:
Run all the tests.
If anything fails, fix it first. Tests gate deployment — nothing ships with failing tests.
Step 2: Deploy:
Deploy the application.
If deployment fails, don't panic — this is common, especially on a first deploy. Your AI assistant will usually see the error and try to fix it automatically. If it doesn't, tell it: "The deployment failed. Help me fix it." Once resolved, try deploying again.
Step 3: When you get a live URL, open it in the browser. Walk through your observation network as a team — submit an observation, check the feed, try the features you built in Run 2.
Team Discussion: The Journey So Far¶
Format: Team Discussion Time: ~2 minutes
You just shipped a live, tested application.
Discuss: Trace the path of a single acceptance criterion through the lifts. It started as part of a delegation contract (Lift 1). It became a manual checklist item (Lift 2). It became an automated test (Lift 3). And it just gated the deployment of a live application. How does each step build on the last? What would be missing if you skipped any of them?
What's Next¶
You've come a long way since Lift 1. You started with the fundamentals — how AI thinks, how to make clear requests, how to write delegation contracts. In Lift 2, you leveled up — decomposing big goals, encoding processes as skills, and reviewing output against acceptance criteria. Now in Lift 3, you've automated verification and shipped a live application.
But notice what's still happening: you're working through your backlog one piece at a time. Write a story. Delegate. Wait. Verify. Move on to the next one. AI is faster than you at building, but you're still the bottleneck — because you can only focus on one workstream at a time. There's so much more you want to build.
In Lift 4, you'll break that bottleneck.
Key Insight¶
Tests gate deployment — they give you the confidence to ship, not just the hope that it works. But shipping isn't the finish line. Every product is built on assumptions about what users need, and deployment is the only way to validate those assumptions. The pipeline loops: Ship connects back to Explore, and what you learn from real users drives what you build next. Your acceptance criteria started as delegation contracts in Lift 1, became manual checklists in Lift 2, became automated tests in Lift 3, and now gate the deployment of a live application — but the real test is whether the people you built it for actually use it.
Up next: Run 3 — time to build with your safety net. Use the closed loop for every feature: criteria, failing test, implement, passing test, redeploy.