[Epic]: Market the care — show how VWC makes good software engineers #1427

🛠 Description

“It's easy to make a software engineer. A good one, within a year, takes a LOT of work.”

That sentence is the message. Parts of it are already on the site, spread across program pages: “Trained to standard, or not trained” (src/data/accelerator.ts:48-51), evidence gates “graded by someone who is not you” (src/pages/programs/mentorship.tsx:41-45), and the mentor's question, “would this survive code review at a real company” (mentorship.tsx:39). The program spans most of that year: 17 weeks in the accelerator (src/data/accelerator.ts:10), then six months of Track 2 after graduation, where a mentor runs mock screens, interview loops and offer negotiation (mentorship.tsx:69-81). But the marketing still leads with outcome numbers nobody can defend.

This epic changes the marketing from outcomes we claim to work we show.

Why effort and proof beat outcome stats

• They need no alumni denominator. A placement rate needs a measurement window and a denominator. [Task]: Add a methodology line to the 97% placement claim #1332 says both are unknown and “must not be guessed”, and src/data/outcomes.ts leaves windowMonths and denominator unset on every stat. A published standard needs neither. Neither does an effort metric such as reviewed PRs per troop in a named cohort.
• They're harder to fake. Anyone can type “97%”. Readers can check a published bar of 375 evidence criteria, a real PR thread with its review comments, and a public repo with its commits.
• The current stats are contested. [Task]: Source or remove the unverified outcome claims #1329 flags 97% placement, $20M+ alumni earnings and 300+ troops trained as unsourced. New marketing built on them would make that problem bigger.
• It fits the brand. The brand guide says VWC chooses “quality over quantity and tangible results over lofty ideals” and doesn't focus on “how many people we can funnel through a pipeline” (docs/brand-style-guide.md:10).

The six moves

1. Publish the bar. Build a public page stating the standard VWC trains every troop to. It uses the Hashflag Graph, where each of the 375 topics has an evidence criterion, and links to the 53 domain pages at /curriculum/<domain>.
2. Show the review. With troop consent, publish a troop's first PR and its review comments next to a later PR. Good engineers are made in code review, and the portfolio checklist already asks for review evidence (item 7-7).
3. Measure effort instead of outcomes. Publish care metrics (human review hours per troop, reviewed PRs before graduation, mentor-to-troop ratio), each with a source and an as-of date so it can be refreshed. None of them needs an alumni denominator.
4. Lead with proof of work. The projects catalog ([Task]: Publish a proof-of-work catalog of troop-shipped projects #1327, shipped in feat(projects): Publish a proof-of-work project catalog #1420) shows real repos and their contributors. Feature strong troop PRs there and in the homepage WorkBelt.
5. State the refusals. Say what VWC won't do (“Not everyone finishes, and that's the point”). Use only statements that are true today, with no numbers to defend.
6. Write for engineers. Publish a blog series on how VWC teaches code review, debugging and testing, aimed at working engineers and hiring managers. Each post ends with an Apply CTA ([Task]: Add an Apply CTA to the Two Pointers blog post #1422/feat(blog): Add an Apply CTA to the Two Pointers post #1425).

Start with: publish the bar

Publish the bar first because it's the only move that needs no data from anyone else. The data already ships in src/data/curriculum-graph/, every one of the 375 topics has a non-empty evidence string, and the 53 domain pages already render them (#1324). The owner still approves the copy and the route, and the graduation-threshold question changes one sentence, not the page. The other five moves point back to it:

• Review examples cite the criterion the review enforced.
• Effort metrics describe the work of reaching the bar.
• Refusals say “we won't graduate you until you meet it”.
• Blog posts explain how a criterion is taught.

Show-the-review, measure-effort and state-the-refusals wait on owner data (consent, numbers, a graduation gate). Proof-of-work and engineer-content wait on the owner's picks (which PRs, which authors). The bar waits only on copy approval.

Sub-issues are linked below.

✅ Acceptance Criteria

• All six sub-issues are closed.
• No section added or changed under this epic states an outcome stat (placement rate, alumni earnings, troops trained, rating) or an “X% within N months across N alumni” line. Outcome stats already on a page this epic touches, such as the homepage funfacts, stay with [Task]: Source or remove the unverified outcome claims #1329 and [Task]: Add a methodology line to the 97% placement claim #1332.
• Every number published under this epic is either computed from repo data at build time (such as the MANIFEST counts) or stored in the repo with a source and an as-of date.

📋 Implementation Notes

Suggested order:

1. publish-the-bar
2. state-the-refusals, since most of its lines are already sourced
3. engineer-content, after feat(blog): Add an Apply CTA to the Two Pointers post #1425 merges
4. proof-of-work, show-the-review and measure-effort, as the owner supplies PR picks, consent and numbers

Copy rules for every sub-issue:

• Write in an imperative, direct voice with uppercase headlines. CTAs are literal words: APPLY, DONATE.
• Learners are troops. VWC is a software engineering accelerator, not a bootcamp. Graduates are software engineers.
• Don't call anything a capstone. src/data/accelerator.ts:54-58 says there is none.
• Use the graph's numbers (375 topics, 529 prerequisite links, 53 domains, 8 subjects), and compute them from MANIFEST in code instead of typing them. Don't mix in the older “25 modules” or “128 Lightcast-validated skills” framing.
• State no mentor-to-troop ratio and no mentor hours until the owner resolves two conflicts in the current copy:
  • Cohort size: 10–15 in src/pages/programs/mentorship.tsx:25 and src/pages/mentor.tsx:37, but a single pairing in src/data/innerpages/faq.json:189 (“we pair you with a working software engineer”) and “your mentee” in mentorship.tsx:70,145.
  • Mentor time: “two hours a month” in src/containers/about/join-cta.tsx:26, but “4–5 hrs / month” in mentorship.tsx:23.
• Don't turn design statements such as “Every week mirrors … code review” or “Every troop pairs with mentors” into counts.
• Don't repeat the unsourced employer list (“Microsoft, Accenture, Amazon…”, src/pages/mentor.tsx:38, mentorship.tsx:145).
• Use brand tokens only (tw-bg-navy, tw-text-gold, red for CTAs), always with the tw- prefix.

Anything a sub-issue lists under Needs from the owner stays off the site until the owner supplies it.

🔗 Related Issues or PRs

• [Task]: Publish the curriculum graph as domain pages #1324: publish the curriculum graph as domain pages (closed). The bar builds on these pages.
• [Task]: Publish a proof-of-work catalog of troop-shipped projects #1327 / feat(projects): Publish a proof-of-work project catalog #1420: proof-of-work projects catalog (issue closed, PR merged)
• [Task]: Build landing pages for the decision queries that convert #1326 / feat(seo): Add landing pages for veteran decision queries #1419: decision landing pages under /for-veterans/ (issue closed, PR merged)
• [Task]: Add an Apply CTA to the Two Pointers blog post #1422 / feat(blog): Add an Apply CTA to the Two Pointers post #1425: Apply CTA on the Two Pointers post (issue open, PR open)
• [Task]: Source or remove the unverified outcome claims #1329: source or remove the unverified outcome claims (open)
• [Task]: Add a methodology line to the 97% placement claim #1332: add a methodology line to the 97% placement claim (open)

🗺️ Issue map

The sub-issues refer to each other by short name:

• publish-the-bar: [Task]: Publish the bar a troop must clear before VWC calls them done #1428 (Publish the bar)
• show-the-review: [Task]: Publish before-and-after pull requests that show how review shapes a troop #1429 (Show the review)
• measure-effort: [Task]: Publish effort metrics in place of outcome stats #1430 (Measure effort)
• proof-of-work: [Task]: Feature strong troop pull requests on project pages and the homepage #1431 (Proof of work)
• state-the-refusals: [Task]: Add a “What we won't do” section to the accelerator page #1432 (State the refusals)
• engineer-content: [Task]: Write a blog series on how VWC teaches code review, debugging and testing #1433 (Engineer content series)