diff --git a/apps/marketing/content/blog/brag-docs-for-developers-who-ship.mdx b/apps/marketing/content/blog/brag-docs-for-developers-who-ship.mdx
new file mode 100644
index 00000000..4b17b6d5
--- /dev/null
+++ b/apps/marketing/content/blog/brag-docs-for-developers-who-ship.mdx
@@ -0,0 +1,143 @@
+---
+title: "Brag Docs for Developers Who Ship"
+date: "2026-01-04"
+description: "Track your full impact: Git commits, GitHub PRs, Jira tickets, and Google Calendar. Built for developers with a CLI-first workflow."
+author: "BragDoc Team"
+tags: ["cli", "git", "developer-tools", "performance-reviews", "career-growth"]
+image: "/screenshots/terminal/bragdoc-extract.png"
+published: true
+canonical_url: "https://www.bragdoc.ai/blog/brag-docs-for-developers-who-ship"
+---
+
+Your impact as a developer is scattered across a dozen systems. Commits in Git. PRs and code reviews on GitHub. Tickets in Jira. Architecture discussions in meetings. Mentoring in 1:1s. No single tool captures all of it.
+
+Keeping a [work log](https://blog.pragmaticengineer.com/work-log-template-for-software-engineers/) is one of the best habits for software engineers. But doing it manually is tedious, and most people give up after a few weeks.
+
+BragDoc automates it. We pull from your Git history, your GitHub activity, your Jira tickets, and your Google Calendar. Everything that represents your work, captured automatically.
+
+But here's what makes us different: we built this for developers, not for everyone.
+
+
+
+## Built for the Terminal
+
+Most productivity tools assume you live in a browser. They want you to click through dashboards, drag cards around, and manually enter your accomplishments. That workflow makes sense for project managers. It doesn't make sense for developers.
+
+BragDoc starts in your terminal. Install the CLI, authenticate once, and you're done:
+
+```bash
+npm install -g @bragdoc/cli
+bragdoc login
+bragdoc init
+```
+
+That's it. Three commands and your repository is configured. No web forms. No onboarding wizards. No fifteen-minute setup tutorials.
+
+When you want to extract achievements from your recent work:
+
+```bash
+bragdoc extract --since 7d
+```
+
+Your commits get analyzed, grouped by theme, and turned into achievement statements. The whole process takes seconds.
+
+
+
+## Your Git History Is Your Brag Doc
+
+Every commit you make is already documentation. The timestamp shows when you did the work. The message explains why. The diff shows what changed. This is more accurate than anything you could write from memory three months later.
+
+The problem isn't that your work isn't documented. The problem is that git log output isn't formatted for [performance reviews](/use-cases).
+
+BragDoc bridges that gap. It reads your commit history, understands the context, and generates achievement statements that make sense to managers. You keep writing commits the way you always have. BragDoc handles the translation.
+
+## Every Source, One Workflow
+
+Real developer work spans multiple systems. You commit code locally. You open PRs and review code on GitHub. You close tickets in Jira. You lead architecture discussions and mentor teammates in meetings. A complete brag doc needs to capture all of it.
+
+BragDoc uses a [pluggable connector architecture](/features) that pulls from wherever your work happens:
+
+- **Git**: Local commits, branches, full diff context. Works offline.
+- **GitHub**: PRs, issues, code reviews, commits, and discussions.
+- **Jira**: Tickets, story points, sprint contributions.
+- **Google Calendar**: Meetings, 1:1s, architecture sessions, planning.
+
+You configure which sources matter for each project through the web app or API. The CLI pulls from all your configured sources automatically:
+
+```bash
+bragdoc extract # All configured sources
+bragdoc extract --project myapp # Specific project only
+bragdoc extract --since 30d # Last 30 days
+```
+
+## Branch Control
+
+Not every branch matters for your brag doc. Experimental work, abandoned features, and one-off debugging branches probably shouldn't appear in your performance review.
+
+BragDoc lets you whitelist branches per project:
+
+```bash
+bragdoc projects add --branch-whitelist "main,develop,release/*"
+```
+
+Only commits from those branches get extracted. Everything else is ignored. This keeps your achievement list focused on work that actually shipped.
+
+## Privacy by Default
+
+Your source code is sensitive. You don't want it uploaded to some cloud service where it might be used to train AI models or leaked in a data breach.
+
+BragDoc processes your code locally. The CLI runs on your machine. Your diffs never leave your computer. Only the generated achievement summaries sync to the server, and even that's optional.
+
+If you want complete control, you can run the entire system locally with [Ollama](https://ollama.ai):
+
+```bash
+bragdoc llm set ollama llama3.2
+```
+
+Now your commits are analyzed by a local model. Nothing touches the internet. Your code stays yours.
+
+
+
+## The Full Picture of Developer Impact
+
+Great developers do more than commit code. You lead architecture discussions. You mentor teammates. You coordinate across teams. You make decisions in meetings that shape the direction of projects. All of that is impact.
+
+Most tools force you to choose: track your code OR track your meetings. BragDoc tracks both. Your commits and your calendar. Your PRs and your 1:1s. The technical work and the leadership work.
+
+The difference is how we do it. We built BragDoc for developers, with a CLI that fits your workflow, integrations that go deep into your tools, and AI that understands technical context. [Learn more about the different types of developer impact](/blog/six-types-developer-impact) and how to document each one.
+
+## For Developers Who Ship
+
+BragDoc is built for developers who ship. If you write code, review PRs, close tickets, and push to production, this is your tool. The CLI fits your workflow. The integrations pull from where your work actually happens. The output reflects your technical contributions.
+
+[Give BragDoc a try](/get-started). Install the CLI, point it at your repositories, and let it capture what you build. Your commits already tell the story of your work. It's time your brag doc did too.
+
+
diff --git a/apps/marketing/content/blog/from-commits-to-performance-review.mdx b/apps/marketing/content/blog/from-commits-to-performance-review.mdx
new file mode 100644
index 00000000..e549d79d
--- /dev/null
+++ b/apps/marketing/content/blog/from-commits-to-performance-review.mdx
@@ -0,0 +1,129 @@
+---
+title: "How BragDoc Turns Git History into Performance Reviews"
+description: "BragDoc's Performance Review feature is shipping now. Generate review-ready documents from your Git history—with AI clustering, streaming generation, and chat refinement."
+date: "2026-01-10"
+author: "BragDoc Team"
+tags: ["engineering", "performance-reviews", "architecture", "building-in-public", "workstreams"]
+image: "/images/blog/from-commits-to-performance-review/pipeline-overview.svg"
+imageAlt: "Diagram showing BragDoc pipeline from Git commits through workstreams to performance review document"
+published: false
+canonical_url: "https://www.bragdoc.ai/blog/from-commits-to-performance-review"
+---
+
+**We're shipping Performance Review document generation.** Starting today, you can select a date range, click generate, and get a review-ready document built from your actual work history.
+
+No more scrolling through six months of commits trying to reconstruct what you did. No more staring at a blank self-evaluation form. Your Git history becomes a polished document you can edit, refine, and submit.
+
+Here's what changed, what's available now, and how the system works.
+
+## What You Can Do Now
+
+The Performance Review feature turns months of scattered achievements into a structured document. Here's the workflow:
+
+1. **Select a date range** for your review period (Q4 2025, last 6 months, etc.)
+2. **Add optional instructions** ("Focus on leadership impact" or "Emphasize technical depth")
+3. **Click generate** and watch your document stream in
+4. **Edit and refine** through a chat interface—ask the AI to expand sections, add metrics, or adjust tone
+
+The document pulls from your achievements and workstreams automatically. If you've been extracting commits with the CLI, you already have the raw material. The Performance Review feature assembles it into something you can actually use.
+
+## How the Pipeline Works
+
+Three stages turn your Git history into a performance review document. Each stage builds on the previous one.
+
+### Stage 1: Extraction (Stable)
+
+The [BragDoc CLI](/features) extracts achievements from your local Git repositories. Your source code never leaves your machine.
+
+```bash
+bragdoc extract --since 6m
+```
+
+The CLI reads your local commit history, analyzes changes with an LLM, and returns structured achievements with titles, summaries, and impact scores. For teams using GitHub, the CLI can also pull PR metadata and code review activity through a separate connector. You can run extraction fully offline using Ollama.
+
+**What this enables:** You stop losing track of what you shipped. Every meaningful commit becomes a documented achievement you can reference later.
+
+### Stage 2: Workstreams (Stable)
+
+Raw achievements get clustered into themes automatically. We use DBSCAN clustering on semantic embeddings to find natural groupings in your work.
+
+Your 50+ achievements become 5-8 named workstreams like "Payment System Refactor" or "API Performance Optimization." Each workstream groups related work across the review period.
+
+**What this enables:** You stop presenting flat lists of accomplishments. Your work gets organized into coherent themes that tell a story.
+
+### Stage 3: Performance Review Document (Shipping Now)
+
+This is the new feature. Select a date range, and the system loads your achievements and workstreams from that period. Add optional instructions, click generate, and the document streams in.
+
+Say you have achievements like "Reduced API latency by 35%," "Implemented Redis caching layer," and "Optimized database queries." The system recognizes these as related—they live in your "Performance Optimization" workstream—and weaves them into a narrative rather than listing them as isolated bullet points.
+
+After generation, you edit through a chat interface. Ask the AI to expand a section, add quantitative impact, or match your company's review format. The document updates in real-time.
+
+**What this enables:** You stop writing performance reviews from scratch. You generate a first draft from real data, then refine it to match your voice and your company's expectations.
+
+## What's Available Now vs Coming Soon
+
+**Stable:**
+- CLI extraction (local Git + GitHub connector)
+- Workstream clustering
+
+**Shipping now:**
+- Performance Review document generation
+- Chat-based document editing
+
+**Coming soon:**
+- Jira integration (in development)
+- Google Calendar integration (on roadmap)
+
+The extraction and clustering infrastructure has been stable for months. The Performance Review feature is new—we're releasing it now for review season. Jira and Calendar integrations will expand what gets captured, but the core pipeline is ready to use today.
+
+## How the Pieces Connect
+
+For those who want the technical details:
+
+```
+CLI (local) Web App Database
+ │ │ │
+ ├─► Extract commits │ │
+ │ (your machine) │ │
+ │ │ │
+ └─► POST achievements ─────────────────►│
+ │ │
+ ├─► Generate embeddings
+ │ (OpenAI API) │
+ │ │
+ ├─► Cluster into │
+ │ workstreams │
+ │ │
+ ├─► [NEW] Generate │
+ │ performance review
+ │ (streaming) │
+ │ │
+ └─► [NEW] Chat │
+ refinement │
+```
+
+The CLI handles extraction locally—your diffs never leave your machine. Only the generated achievement summaries sync to the server. When we generate embeddings for clustering, we're embedding those summaries, not your source code. The web app handles clustering and document generation. The new Performance Review feature sits at the end of this pipeline, consuming all the data you've already captured.
+
+## Try Performance Review Generation
+
+If you're preparing for a review cycle, here's how to get started:
+
+1. **[Install the CLI](/get-started)** and run `bragdoc extract --since 6m` on your repositories
+2. **Open the web app** and navigate to Performance Reviews
+3. **Create a new review** with your date range
+4. **Generate your document** and refine it until it's ready to submit
+
+You'll end up with a review draft organized by workstreams, ready to copy into your company's review form or export as-is.
+
+The first draft takes seconds. Refinement takes as long as you need. Either way, you're starting from your actual work history instead of a blank page.
+
+---
+
+**This is what we're putting in your hands now.** Performance Review document generation is built for engineers facing review season, promo packets, or compensation conversations. Your Git history already contains the evidence of what you accomplished—we're making it usable.
+
+Questions or feedback? Open an issue on GitHub or email us at hello@bragdoc.ai.
+
+**Related**: [Why Developers Need Automated Brag Docs](/blog/why-developers-need-automated-brag-docs) explains the problem in more depth. [Six Types of Developer Impact](/blog/six-types-developer-impact) covers what to include beyond code.
+
+
diff --git a/apps/marketing/content/blog/the-promotion-gap-why-great-engineers-get-overlooked.mdx b/apps/marketing/content/blog/the-promotion-gap-why-great-engineers-get-overlooked.mdx
new file mode 100644
index 00000000..6edd88d9
--- /dev/null
+++ b/apps/marketing/content/blog/the-promotion-gap-why-great-engineers-get-overlooked.mdx
@@ -0,0 +1,98 @@
+---
+title: "The Promotion Gap: Why Engineers Get Overlooked"
+description: "Research reveals how bias affects tech promotions. Why great engineers get passed over—and what you can do about it."
+date: "2026-01-09"
+author: "BragDoc Team"
+tags: ["promotion", "career-growth", "bias", "performance-reviews", "engineering-careers"]
+image: "/images/blog/the-promotion-gap/promotion-gap-data.svg"
+imageAlt: "Infographic showing promotion gap statistics: less than 10% of engineers are Staff level, 50%+ of rating variance is rater bias, 42% of managers forget remote workers, 66% of devs say metrics miss contributions"
+published: false
+canonical_url: "https://www.bragdoc.ai/blog/the-promotion-gap-why-great-engineers-get-overlooked"
+---
+
+You've shipped more features than your peers. You've fixed critical bugs that saved the company money. You've mentored junior developers. Yet when promotion season arrives, someone else gets the title.
+
+This promotion gap happens far more often than it should. And it's probably not because you're not good enough.
+
+Research suggests that systematic biases in how we evaluate engineers create patterns where excellent work goes unrecognized. This doesn't explain every missed promotion, but it explains more than most engineers realize.
+
+
+
+## The Core Problem: Your Rating Depends on Who's Rating You
+
+If there's one number that matters most, it's this: more than 50% of performance rating variance comes from rater bias, not actual performance differences.
+
+More than half the difference between your rating and your peer's rating has nothing to do with how good you actually are. It's about who's doing the rating, their preferences, and what they happen to remember.
+
+## How Bias Shows Up in Practice
+
+Two biases matter most:
+
+**Proximity bias** affects who gets seen. 42% of managers admit they forget about remote workers when assigning high-visibility work. Your manager sees the person sitting next to them every day. They remember that person's wins.
+
+**Recency bias** affects what gets remembered. Recency bias is one of the most common biases in performance reviews—managers give disproportionate weight to what happened in recent weeks rather than the full review period. The engineer who shipped something visible last week beats the engineer who shipped something critical in March.
+
+These biases compound. If you're remote and your biggest wins happened early in the review cycle, you're fighting an uphill battle that has nothing to do with the quality of your work.
+
+## What This Looks Like in Practice
+
+Consider two engineers on the same team. Both are senior. Both are technically strong.
+
+Engineer A works from home. In February, she led a complex database migration that prevented a potential outage affecting thousands of users. In her 1:1s, she mentioned it briefly. She didn't write it down anywhere else.
+
+Engineer B sits two desks from their manager. In October—three weeks before reviews—he shipped a visible dashboard feature. Nothing critical, but the whole team saw the launch. His manager mentioned it in the weekly standup.
+
+Come December, the manager writes performance reviews. The migration? It's been ten months. The specifics are fuzzy. The dashboard? Fresh in mind, easy to describe, clearly impactful.
+
+Engineer B gets the stronger review. Not because he's better—because his work was recent and visible.
+
+This isn't a story about bad managers. It's a story about how memory works, and what happens when documentation doesn't exist.
+
+## The Structural Reality
+
+According to Levels.fyi research, staff engineers typically make up less than 10% of engineering organizations. The senior level is a "career level" by design—most engineers who reach it stay there.
+
+This isn't necessarily bad. Not everyone wants to be a staff engineer, and that's valid. But for those who do want to advance, internal promotions to staff are notoriously difficult. At competitive levels, visibility can be the deciding factor between candidates of similar ability.
+
+## What the Data Doesn't Explain
+
+Before we talk about solutions: limitations matter.
+
+A missed promotion might be bias—or it might be that you weren't ready, that there wasn't headcount, or that your manager had legitimate concerns. Documentation helps in organizations that are fundamentally fair but imperfect. It doesn't help in toxic environments. It doesn't replace having a manager who advocates for you.
+
+If good documentation and consistent performance still don't move the needle, the problem might not be your visibility. It might be the organization.
+
+## What You Can Actually Do
+
+For engineers in reasonably functional organizations, visibility gaps are often fixable:
+
+- **Document wins as they happen.** Julia Evans' brag document approach captures achievements when they occur, not six months later. (See our guide on [how to write a self-evaluation](/blog/how-to-write-self-evaluation-developer).)
+- **Be specific about impact.** "Fixed a bug" is forgettable. "Fixed a race condition causing 2% transaction failures, protecting $50K/month revenue" is not.
+- **Share wins regularly.** Distribute when your manager learns about your work across the year to counteract recency bias.
+
+These aren't guaranteed solutions. They're habits that tend to help in environments where effort is generally rewarded.
+
+## Why We Built BragDoc
+
+We kept noticing the same pattern: engineers scrambling before review season, trying to reconstruct months of work from vague memories and incomplete git logs. The same struggle showed up in job searches, salary negotiations, and even weekly standups.
+
+[BragDoc](/features) pulls from Git history, GitHub activity, and other sources to capture achievements automatically. Your commits already document what you did and when—we translate that into statements you can actually use.
+
+It won't fix broken organizations or guarantee promotions. But for engineers in environments where documentation matters, it removes the part where you have to remember everything yourself.
+
+Whether you're preparing for [performance reviews](/use-cases), negotiating a raise, or maintaining a clear record of your trajectory, documented evidence tends to improve your odds.
+
+---
+
+**Next steps:** Start documenting your wins this week. Add three recent accomplishments to a simple document, then capture each new win as it happens. By review season, you'll have clearer evidence of your impact—and a better foundation for whatever conversation comes next.
+
+
diff --git a/apps/marketing/public/images/blog/from-commits-to-performance-review/pipeline-overview.svg b/apps/marketing/public/images/blog/from-commits-to-performance-review/pipeline-overview.svg
new file mode 100644
index 00000000..7d24834d
--- /dev/null
+++ b/apps/marketing/public/images/blog/from-commits-to-performance-review/pipeline-overview.svg
@@ -0,0 +1,132 @@
+
\ No newline at end of file
diff --git a/apps/marketing/public/images/blog/the-promotion-gap/promotion-gap-data.svg b/apps/marketing/public/images/blog/the-promotion-gap/promotion-gap-data.svg
new file mode 100644
index 00000000..0bc869cd
--- /dev/null
+++ b/apps/marketing/public/images/blog/the-promotion-gap/promotion-gap-data.svg
@@ -0,0 +1,80 @@
+