06 — The Capstone Scope Creep¶
Failure mode: Capstone Alpha (MiniServe — a tiny C++ inference server that loads an ONNX/TorchScript model and serves HTTP predictions) grows in scope until it tries to compete with NVIDIA Triton. Feature list explodes: gRPC, batching, dynamic tensor shapes, tokenizer, streaming, Prometheus metrics, multi-model. Six weeks in, no end-to-end path works. Capstone never ships. Portfolio is empty at M13.
Probability: 45%
Capstones are where ambitious people fail. The whole roadmap has been building toward this moment. The urge to make it matter is strong. The trap is thinking that “matters” means “impressive feature list” rather than “actually works end-to-end.”
Why It Happens¶
The impressive-portfolio fallacy. Raghul imagines a reviewer at a hiring manager screen. He wants the reviewer to say “wow, that’s real.” He starts adding features to guarantee wow. Every feature delays the wow.
Comparison to real inference servers. He reads the Triton architecture doc, the TorchServe README, vLLM’s whitepaper. Each has 30+ features. He starts feeling like his 3-feature MVP is embarrassing.
The “one more thing before shipping” trap. Every feature is “just 2 more days.” Six 2-day features = 3 weeks. Repeat that twice = 6 weeks and no ship.
Perfectionism about the README. Wants a beautiful architecture diagram, benchmark charts, comparison table before the first commit is public. None of it exists at M11 W2 and the deadline is M12.
Fear of shipping ugly. Once it’s public, people can criticize it. Not-shipping-yet is safer for the ego.
Early Warning Signals¶
>6 weeks into capstone work and no end-to-end path exists. End-to-end =
POST /predictreturns a real number from a real model file. If that request doesn’t work, nothing else matters yet.README file has been edited more times than actual code files in the last 2 weeks.
Feature list on the whiteboard/notes has grown from initial scope, not shrunk. Capstones should shed features over time as reality bites, not gain them.
Comparing MiniServe to Triton/vLLM in casual conversation as if that is the frame of reference. It is not. The frame is “the smallest working thing that demonstrates the skill.”
Nothing pushed to public repo yet and it is past M11 W4.
Mitigation — The MVP Rule¶
A working shitty version by W48 (M12 W4). Polish comes only after the shitty version is shipped, tagged, and public.
The MVP definition, in one sentence:
A C++ HTTP server that loads a single ONNX model at startup, accepts POST /predict with a JSON tensor input, runs inference, returns a JSON tensor output. That’s it.
The MVP does not need:
Batching (add in v0.2 if time)
gRPC (add in v0.2 if time)
Multi-model support (add in v0.3 if time)
Streaming responses (never, not in this capstone)
Prometheus metrics (add in v0.2)
Fancy tokenizer (never — pre-tokenized inputs are fine)
Dynamic shape handling (add in v0.3)
Docker image (add in v0.2)
Benchmark vs Triton (add in v0.3, and be honest — you will lose, and that is fine)
The MVP does need:
A single working POST /predict path
A 1-page README showing how to run it and get a prediction
One example curl command that returns a real number
A tiny test script that hits it and asserts the response format
Ship the MVP. Then, and only then, add features.
Weekly Ship Rule (M11–M12)¶
During the capstone build phase:
Every Sunday of M11–M12, something new is pushed to the public repo. Not necessarily a feature. Could be a doc update, a test, a refactor. But the repo shows commits every week. This is both discipline and portfolio signal.
By end of M11: the “load model + return dummy prediction” skeleton is live. No real inference yet — just prove the HTTP path works with a hardcoded response.
By M12 W2: real inference on a real model. Ugly, slow, single-threaded. Fine.
By M12 W4: v0.1.0 tag, 1-page README, curl demo works, repo public. MVP shipped.
M13: polish, second capstone, or study conversion. Whichever the roadmap allocates.
Escalation Trigger¶
If M12 W2 arrives and no real inference is working:
Cut features by 50% immediately. Whatever is on the list, halve it. Ruthlessly.
Drop to single-model, single-input-shape, no batching, no metrics. Bare-bones only.
If M12 W4 arrives and the MVP is still not shipped: ship whatever exists as v0.0.1-alpha with a README that literally says “early prototype, load-and-predict path only.” Shipping the ugly thing is infinitely better than not shipping.
Blog about the cut. A post titled “MiniServe: what I cut from my C++ inference server MVP” is a stronger portfolio signal than a feature-complete server would have been. It shows engineering judgment.
The Reframe¶
Hiring managers looking at Raghul’s portfolio at M13 want to see:
Does the repo build? (Green CI badge.)
Does the README explain what it does in 30 seconds? (Yes/no.)
Does the demo work when I clone and run? (Critical.)
Is there a story in the commit history — did this person iterate? (2026-specific: several study partners now literally scroll commit history.)
What did they choose NOT to build, and why? (Judgment signal.)
They do not need to see it beat Triton. They need to see it exist, work, and be honestly described.
The Second Capstone¶
Capstone Beta (M13) — a smaller applied project, like a C++ tokenizer or a batching layer that plugs into MiniServe — is planned as a second portfolio piece. If MiniServe scope-creeps and eats M13, Beta doesn’t ship. That is fine. One shipped capstone with a clean story beats two half-baked ones.
The rule: Alpha ships fully before Beta starts. No parallel capstones. No “I’ll work on both.”
What Success Looks Like at End of M12¶
miniserverepo public, ≥ 20 commits, v0.1.0 tag, green CI.README with a working curl example.
One blog post: “Building MiniServe: a tiny C++ inference server in 5 weekends.”
The MVP works. Not fast. Not fancy. Works.
Lab notebook: “Capstone Alpha shipped. What I cut and why.”
That is a hireable portfolio piece. Everything past that is upside.
Nav: ← 05_the_hard_gate_M9_miss.md · → 07_the_interview_fail_spiral.md