Four steps before any code ships.

The discipline is the deliverable as much as the code is. SCOPE before PLAN, PLAN before BUILD, BUILD before SHIP — and at every gate, the customer can change their mind without it costing more than a conversation. Phase 1 is fixed-price; Phase 2 (if there is one) is its own SCOPE. There is no continuous engagement, no monthly retainer, no scope creep masquerading as “while you’re in there.”

1. 01
   SCOPE
   One document. Signed before any code.

   The first conversation is free. We talk about what you’re trying to do, what you’ve tried, and what done would look like. I leave with notes; you leave with nothing yet — that’s the point. A few days later, a written SCOPE.md document arrives in your inbox.

   It’s short. Maybe two pages. Opinionated. It names what’s in scope as carefully as what’s out, and it has an open-questions list for things we haven’t pinned down. You read it, push back, revise — usually one or two rounds. Then we both sign off, and a fixed price is set for Phase 1.

   The OUT-of-scope list is doing as much work as the in-scope one. It’s the discipline that keeps Phase 1 small enough to ship in weeks, not months — and small enough to know how much it’ll cost. Anything new becomes a Phase 2 conversation. Nothing slips in via “while you’re in there.”

   SCOPE.md shape

   # SCOPE — engagement template ## Engagement - Customer: [name] - User: [who actually uses it day-to-day] - Budget: [fixed price] - Delivery: [target ship date] ## The ask [One or two paragraphs naming the wedge — what they’re trying to do, what they’ve tried, what done looks like.] ## In scope (Phase 1) - [...] - [...] ## OUT of scope (Phase 2 or never) - [Phase 2 candidate] - [Phase 2 candidate] - [Never — doesn’t fit this customer] - [Never — generic-tool drift we said no to] ## Open questions 1. [Things still TBD] 2. [...]
   Typically 1–2 weeks Deliverable SCOPE.md (signed) Gate you sign off before any plan
2. 02
   PLAN
   The implementation strategy. Concrete enough to argue with.

   After SCOPE is signed, I go away for a few days and write PLAN.md. It’s the implementation strategy — concrete enough for you to push back on, abstract enough to not pretend to be code.

   The plan names the architectural decisions in plain terms (single-Worker vs. microservices, build step or no, ORM or hand-written SQL — and why each call was made), the build order so you know what gets done first, and a risks list with mitigations so you learn what could go wrong before it does.

   You read the plan, push back, sign off. Then code starts. The plan is short enough that you can read it in fifteen minutes — you should never feel like you’re rubber-stamping something you don’t understand.

   PLAN.md shape

   # PLAN — implementation strategy ## Architectural decisions 1. [Decision]. [Brief why — e.g., “Single Worker, single D1, single HTML page. The whole tool fits in one runtime.”] 2. [Decision]. [Brief why] 3. [Decision]. [Brief why] ## Build order - [What ships first, and how it’s testable on its own] - [What’s next, and what’s safe to add later] - Phase 1 isn’t done until [a real test passes] ## Risks - [Risk] → mitigation: [how we hedge] - [Risk] → mitigation: [how we hedge]
   Typically 2–7 days Deliverable PLAN.md (signed) Gate you sign off before any code
3. 03
   BUILD
   Heads-down, with a working preview from day one.

   Two to four weeks of focused work, depending on Phase 1 size. As soon as something runs, you get a preview link — and you keep getting that same link as features land. You’re not waiting for a launch event; you can use the tool while it’s being built.

   Status comes in plain English, not Gantt charts. Daily check-ins by email if you want them, weekly if that’s enough. The honest version: this week I shipped X, next week I’m doing Y, blocked on Z. No stand-ups, no Jira tickets, no Slack threads chasing decisions.

   If something looks off in the preview, we course-correct now — not at launch when it’s expensive.

   SubjectStatus — week of [date] FromEric

   Hi [name] —

   Last week

   • Shipped the price-book CRUD UI; you can edit prices from the admin screen now.
   • Wired drift detection — the summary card flags when a quote’s prices have moved.
   • Spent half a day untangling a foreign-key issue on the estimates table; clean now.

   This week

   • Estimator wizard — project info → items → summary flow.
   • If time, the PDF export.

   Blocked on

   • Nothing right now. The Plumbing item from your sample workbook had a typo (M3-1.5 vs M3-1.5x) — using the second per our last email; flag if wrong.

   Preview as it stands: [yourdomain]/preview-w17

   Eric

   Typically 2–6 weeks Deliverable working preview at your own domain Cadence daily or weekly check-ins, your call
4. 04
   SHIP
   Running app, source, runbook. Yours.

   The app goes live at your own domain. The source code lives in your repo. The database schema, the seed scripts, the runbook for keeping it running — all yours.

   A 30-to-60-minute walkthrough covers how to deploy, where to look when something breaks, and what the common ops tasks look like. The RUNBOOK.md document is plain English; you don’t need a developer in the room to read it.

   After ship, I’m available for follow-up questions and small things. If you decide to extend the tool — Phase 2, Phase 3 — that’s a new SCOPE conversation, fixed price again. If you decide to bring on a different developer to maintain it, you have the source code to hand them. Ownership is the deliverable as much as the code is.

   Typically 1 day Deliverables app, source, schema, runbook, walkthrough Next optional Phase 2 conversation