Zero to Deployed in Five Minutes

The Vibe Guide, Part 2 of 6 — The Abyss Drift case study

The Receipt

Before the theory, the proof: abyssdrift.pages.dev — a full underwater ocean game. Drift through the deep, dodge what needs dodging. On mobile, it reads your device's IMU (accelerometer/gyroscope), so you steer by tilting the phone.

Total time from empty prompt to live URL: about five minutes.

Not five minutes of AI generation followed by an afternoon of glue work. Five minutes, end to end, including deployment. This part breaks down exactly how, and — more importantly — why this workflow generalizes.

The Setup (One-Time, ~10 Minutes)

1. Install Quests from quests.dev. It's a desktop app (Mac/Windows/Linux), lightweight, no dependency circus.
2. Add a model. Quests is bring-your-own-key: OpenAI, Anthropic, Groq, DeepSeek, a local Ollama model, or anything OpenAI-compatible via OpenRouter. Pick a strong coding model — this is the one place not to cheap out on your first run. (You can run evals later inside Quests to compare models on your actual prompts.)
3. That's it. No account tiers, no credit dashboard, no onboarding funnel.

The Build

Step 1: The prompt

Open a new tab in Quests and describe the game like you'd describe it to a talented developer who's about to disappear for five minutes:

Build an underwater drifting game. The player is a small submersible descending through an endless procedurally-varied ocean. Obstacles drift past; the player steers to avoid them. Depth is the score. Ambient deep-ocean visual style — dark blues, bioluminescent accents, particle drift. Desktop: arrow keys or WASD. Mobile: use the device motion API (IMU) so the player steers by tilting the phone, with a permission prompt on iOS. Include a start screen, death/restart flow, and a persistent best-depth score.

Notice what this prompt does:

• Names the mechanic, not the implementation. "Depth is the score" beats three paragraphs about game loops.
• Specifies the platform edge case up front. iOS requires an explicit user gesture to grant DeviceMotionEvent permission. Saying so in the prompt saves an entire debug cycle.
• Describes vibe with concrete anchors. "Dark blues, bioluminescent accents, particle drift" gives the agent an aesthetic to converge on instead of defaulting to gray-box.

Step 2: Watch it work (and interrupt when useful)

Quests' agent does targeted file edits with real-time linting — it writes, checks itself, and fixes errors as it goes. You get an instant local preview because everything runs on your machine. No sandbox spin-up, no cloud queue.

This is where the local-first design pays off practically: the iteration loop is preview → one-line follow-up prompt → preview, measured in seconds. Ours went roughly:

• "Obstacles feel too sparse after depth 500 — ramp density with depth."
• "Tilt steering is too twitchy — add smoothing/deadzone."
• "Make the bioluminescence pulse subtly."

Each of these on a credit-metered platform is a small financial decision. Here it's just... iterating. That psychological difference changes how much polish actually happens.

Step 3: The IMU bit (the part that impresses people)

Mobile motion control sounds exotic; it's actually a small amount of well-known web API code — which is exactly what coding agents are best at producing correctly:

• DeviceMotionEvent / DeviceOrientationEvent listeners
• The iOS 13+ requestPermission() dance, gated behind a tap on the start button
• A smoothing filter and deadzone so hands aren't gyroscopes
• Graceful fallback to touch/keyboard when the API is unavailable

The agent handled all four because the prompt asked for them. Lesson: the more precisely you name the hard 10%, the more of it the agent does for you.

Step 4: Ship it

The output is a standard project on your disk — real files, real Git. For a static-friendly game like this, deployment to Cloudflare Pages is:

git init && git add -A && git commit -m "abyss drift v1"
# push to a repo, connect it in the Cloudflare Pages dashboard
# — or skip the dashboard entirely:
npx wrangler pages deploy dist

Live URL. Global CDN. Free tier. Done. (Part 4 goes deep on when Pages vs. Vercel vs. your own metal is the right call — for a static game, Pages is close to unbeatable.)

Why This Beats the Hosted Builders for This Job

The hosted builders would have gotten a playable something quickly too. The difference shows up at minute six: we already had a clean local repo, our own deploy target, and zero platform dependencies. That's the position of strength everything else in this series builds from.

The Open Source Multiplier

One more thing before we move on, because it's the thread that runs to Part 6: Quests being open source (Apache 2.0) means the ceiling isn't the product roadmap. The same agent workflow that built a browser game can be studied, modified, and pointed at more sophisticated targets — firmware helpers, device dashboards, edge service scaffolding. When the tool is a black box, your ambitions are capped at its feature list. When it's open source, its feature list is a starting point.

What You Should Take Away

1. Five minutes is real, but it's five minutes because of the setup around it — a good model, a precise prompt, a deploy pipeline you already trust.
2. Name the hard 10% in the prompt. Platform quirks, permissions, edge cases — front-load them.
3. Local-first removes the iteration tax, and iteration is where quality comes from.
4. A prototype is done when it's deployed, not when it runs on localhost. Always finish the rep.

But let's be honest about what we have: a great prototype. The code works, but it hasn't been engineered. Structure, tests, performance passes, accessibility, the stuff that makes software survive contact with real users —

Next: Part 3 — The Handoff, where we carry the project into VS Code + Claude Code and turn vibe output into something you'd put your name on.