Phase 7 — Capstone Shipping Checklist¶

Two capstones. Twelve weeks. This file is the operational checklist that turns “mostly working on my laptop” into “linked from my LinkedIn and demoed on a stranger’s screen”. Treat every unchecked item like a failing test — the capstone is not shipped until the box has a tick.

The gap between “code compiles” and “shipped” is where most engineers lose the year. Everything below exists to close that gap.

What “shipped” actually means¶

A capstone is shipped when a stranger — not you, not a peer, not your mentor — can land on the repo cold and, within ten minutes, understand what it does, why it matters, how fast it is, and how to run it themselves. That is the entire bar. If any of those four questions requires them to DM you, the capstone is not shipped.

Concretely, “shipped” means the ten items in the section below are all done. Not eight of ten. Ten of ten. The last two always feel skippable — they are the two that convert.

The ten-item shipping bar¶

Every capstone (Alpha and Beta) clears all ten before the launch tweet goes out.

#	Item	Why it matters
1	README that answers what/why/how/how-fast in the first screen	Recruiters and HN readers give you 20 seconds
2	Architecture diagram (one image, PNG in `/docs`)	System-design signal without them reading code
3	Reproducible benchmark script + methodology paragraph	The number without the methodology is discarded by anyone who knows
4	Benchmark table with concrete numbers vs a named baseline	“Faster” without a baseline is meaningless
5	Demo GIF or 90-second video embedded in README	Halves the “should I clone this?” friction
6	Working `docker compose up` (Alpha) or `pip install` (Beta) — one command to try	The moment they hit a build error, you lost them
7	LICENSE (MIT or Apache-2.0 — pick one, be consistent across both capstones)	No license = no adoption
8	CONTRIBUTING.md — even a 200-word version	Signals you expect contributors, which signals maturity
9	CI on push (GitHub Actions) — build + test badges in README	Green badges are trust signals
10	Deployed live demo (Alpha: $5 VM URL; Beta: Colab notebook link)	Removes the last friction between reader and product

Items 5, 6, 10 are the ones you will be tempted to skip. Do not.

README quality bar¶

The README is the artifact. Repos are read like landing pages, not like books — top-to-bottom, first screen matters most, then scanning for headings, then maybe a section or two in depth.

Required section order (both capstones):

One-line description — 15 words or fewer, plain English.
Hero benchmark — one number vs one baseline, on the first screen. Example: “3.2× throughput of FastAPI+PyTorch at p99 < 20ms on M2 Pro.”
Demo GIF or video — 30-90 seconds, embedded above the fold.
Quick start — three commands maximum. If it takes more than three, your setup is broken.
What this is / what this is not — anti-features section. Signals mature scope.
Architecture — diagram + two paragraphs.
Benchmarks — table, methodology paragraph, reproduction script link.
Roadmap — three bullets of what’s next. Even if you never do them, having a roadmap signals ownership.
License · Contributing · Contact — footer.

What most people get wrong: they put installation and API reference above benchmarks. Reverse that. The reader decides in the first screen whether to keep reading, and they decide based on the number, not the API.

Demo artifact — GIF or video¶

You will resist this step. Do it anyway.

Alpha (MiniServe): 90-second screencast — terminal panel running ghz load test on one side, Grafana dashboard on the other side, watch p99 hold steady as concurrency ramps 1 → 128. Narration optional; captions preferred so it plays silently on LinkedIn.
Beta (PyFast): 60-second GIF — Jupyter cell shows pip install pyfast_ann, index build on 1M vectors, query with numpy return, side-by-side with sklearn.NearestNeighbors wall-clock.

Tools: QuickTime (Mac built-in) → GIPHY Capture for GIF conversion, or asciinema for terminal-only. Under 5 MB — GitHub won’t render larger inline.

Benchmark table — the format that converts¶

Bad benchmarks lose you credibility faster than no benchmarks. Structure yours as:

| Workload | Baseline (v, config)     | MiniServe (v, config) | Ratio | p50    | p99    |
|----------|--------------------------|-----------------------|-------|--------|--------|
| c=1      | FastAPI 0.115 + PT 2.4   | v0.1.0 default        | 1.4×  | 6.2ms  | 11ms   |
| c=8      | FastAPI 0.115 + PT 2.4   | v0.1.0 default        | 2.1×  | 8.8ms  | 22ms   |
| c=32     | FastAPI 0.115 + PT 2.4   | v0.1.0 default        | 2.9×  | 15ms   | 47ms   |
| c=128    | FastAPI 0.115 + PT 2.4   | v0.1.0 default        | 3.2×  | 41ms   | 128ms  |

Under the table, one paragraph: hardware, warmup, duration, reps, load generator, model, batch config. Under that paragraph, a link to the reproduction script. Someone should be able to run one command and get numbers within ±10% of yours. If they can’t, your benchmark isn’t real.

Architecture diagram¶

One PNG, checked into /docs/architecture.png, referenced in README. Tools: excalidraw.com (fastest, hand-drawn feel signals scale-appropriate humility), draw.io (denser), mermaid in-README (works but renders differently across platforms — prefer PNG).

Show: request path, batching queue, thread pool, model executor, metrics/tracing pipes out. Label the interesting parts (backpressure boundary, batching window, OTel span boundaries). Do not draw every component — draw the ones that make the tradeoffs visible.

Timeline gates — no negotiation¶

The dates below are hard gates. Missing one triggers a scope cut, not a schedule slip.

Gate	Week	Deliverable	If missed, cut
M11 kickoff	W45	Both capstone specs finalized, repos created public with README skeleton	Nothing yet — but repo public forces commitment
Alpha alpha	W48	MiniServe: gRPC + REST + inference working, docker compose up runs, first benchmark on your laptop	Cut multi-model support; ship single-model first
Alpha shipped	W52 (end of M12)	All 10 shipping-bar items green, live demo URL, blog post drafted	Cut REST endpoint; keep gRPC + curl proxy
Beta shipped	W53	PyFast on Test-PyPI, notebook demo, benchmark table published	Cut cross-platform wheels; ship Linux+macOS only
Polish + rehearsal	W54	Both READMEs re-read cold by a peer, blog posts published, pitch versions rehearsed	Cut the “polish week” is not optional
Launch	W55-W56	HN Show HN + r/cpp Show-Off + LinkedIn + 5 recruiter DMs	Nothing — this is the point

The pattern: Alpha ships four weeks before Beta because Alpha is the heavier artifact. Do not swap the order.

Scope cut protocol¶

You will hit a wall. Every builder does. When you do, cut features in this order:

First: cut cosmetics (logo, custom theme, animations, fancy CLI colors).
Second: cut edge cases (unusual model shapes, obscure OS support, edge-case error paths).
Third: cut non-must-have features (see each capstone’s non-features list — those are your first-round cuts).
Fourth: cut a benchmark tier (drop c=128, keep c=1/8/32).
Last resort: cut a whole feature and update the anti-features list in the README explaining why.

Never cut: the ten shipping-bar items. Never cut: the benchmark methodology paragraph. Never cut: the demo GIF.

First external star / issue / PR¶

The single strongest signal that Phase 7 worked is that a stranger interacts with your repo without being asked. Track these:

First non-you star — screenshot, keep in your journal. Do not celebrate publicly.
First non-you issue — respond within 24 hours, courteously, regardless of quality.
First non-you PR — even a typo fix. Merge it fast if it’s clean; explain politely if it isn’t.

If you get zero of these by W56, that is not a failure of the capstone — it is a signal about the launch, and it means either the target audience never saw it or the README lost them on the first screen. Diagnose from the analytics on your landing page, not from your feelings.

The M13 launch week — hour-by-hour¶

W55 or W56, pick the week. Both capstones ready. Blog posts drafted. Then:

Monday 8am IST — publish the blog post version for Alpha to your domain.
Monday 10am IST — LinkedIn post linking blog + repo + demo GIF. Tag no one; hashtags: #cpp #machinelearning.
Tuesday 8am ET (6:30pm IST) — Show HN for Alpha. Title format: “Show HN: MiniServe – C++ ML inference server, {X}× FastAPI+PyTorch”. First comment: your explanation of why you built it and what feedback you want.
Wednesday — respond to every comment on HN and LinkedIn. Do not argue; ask clarifying questions to critics.
Thursday — r/cpp Show-Off Saturday preview post if Saturday falls in W55/W56, or straight post.
Friday — 5 personalized DMs to Tier A/B engineers linking the launch post + asking for a 15-min chat.
Saturday — Publish Beta blog post + PyPI announcement. Same launch sequence one week later.

Total time: ~15 hours over two weeks. This is the payoff sprint. Sleep normally, eat normally, run the loop.

Post-launch — the trailing tail¶

After the launch week, momentum drops fast. To keep the capstones alive as recruiter bait for months after:

Small commit at least weekly (bug fix, doc improvement, new benchmark) — keeps the repo “actively maintained” badge honest.
Respond to every GitHub issue and PR within 48 hours.
One follow-up blog post per capstone in the two months after launch — “what I learned running it in production”, “the bug that took me a week to find”, “one benchmark I got wrong”.
Roll up screenshots of your first star, first issue, first PR into a “traction” section on the landing page after 3 months.

The capstones are not one-time shipping events. They are living exhibits. Treat them like the portfolio pieces they are, and they will pay you back for the next 3-5 years.

Nav: ← 06 The M13 Pitch · Phase 7 README · Roadmap root