diff --git a/apps/web/content/articles/company-handbook-in-public.mdx b/apps/web/content/articles/company-handbook-in-public.mdx
index 1410afc008..055faadcd2 100644
--- a/apps/web/content/articles/company-handbook-in-public.mdx
+++ b/apps/web/content/articles/company-handbook-in-public.mdx
@@ -1,5 +1,5 @@
 ---
-display_title: "Why We''re Publishing Our Company Handbook"
+display_title: "Why We're Publishing Our Company Handbook"
 meta_title: "Why We're Publishing Our Company Handbook at Hyprnote"
 meta_description: "Why early-stage companies are built on founder philosophy, not just products—and why we're publishing our company handbook openly at Hyprnote."
 author: "John Jeong"
@@ -7,8 +7,6 @@ created: "2025-12-12"
 published: true
 ---
 
-Why We're Publishing Our Company Handbook at Hyprnote
-
 In the early days of a startup, engagement doesn't come from feature lists or polished landing pages.
 
 It comes from how the founders see the future.
@@ -17,26 +15,26 @@ Before companies had traction, they had manifestos. Before metrics, they had bel
 
 That's why we decided to publish our company handbook openly at Hyprnote.
 
-Two Documents, Not One
+## Two Documents, Not One
 
 At the start of Y Combinator, a visiting partner named Eli shared something that stuck with me.
 
 When he was trying to hire exceptional engineers, he never sent just one document. He sent two.
 
-The first was straightforward: requirements.
+The first was straightforward: requirements.  
 The tech stack, the tools, how things worked on a day-to-day basis.
 
-The second was harder to write: expectations.
-How decisions are actually made.
-What ownership really means.
+The second was harder to write: expectations.  
+How decisions are actually made.  
+What ownership really means.  
 What "doing a good job" looks like inside the company.
 
 At the time, this sounded like a hiring tactic. Only later did I realize the second document was doing most of the work.
 
-Requirements filter for ability.
+Requirements filter for ability.  
 Expectations filter for alignment.
 
-What Most Early-Stage Companies Don't Write Down
+## What Most Early-Stage Companies Don't Write Down
 
 Most startups are very good at explaining what they're building.
 
@@ -50,7 +48,7 @@ Our code is public by default. Anyone can read it, audit it, or contribute to it
 
 We didn't want that asymmetry.
 
-Why Put a Handbook on the Website?
+## Why Put a Handbook on the Website?
 
 Publishing a company handbook publicly isn't about transparency as a virtue signal.
 
@@ -62,11 +60,11 @@ That's why some of the most respected open-source companies — like GitLab, Cal
 
 We believe authentic writing — especially early on — creates more meaningful engagement than any polished marketing copy ever could.
 
-What Our Handbook Is (and Isn't)
+## What Our Handbook Is (and Isn't)
 
 The Hyprnote handbook is not a rulebook.
 
-It's not a list of corporate values.
+It's not a list of corporate values.  
 It's not a finished product.
 
 It's a snapshot of how we define good work, ownership, communication, and trust — right now.
@@ -75,13 +73,13 @@ Some parts may change. Some beliefs may evolve. That's expected. What matters is
 
 For us, writing this down is slightly uncomfortable. And that's exactly why it matters.
 
-An Invitation
+## An Invitation
 
 If you're building a company — especially an open-source one — I'd encourage you to ask:
 
 What expectations exist in your company that everyone "just knows," but have never been written down?
 
-And if you're reading this as a contributor, user, or future teammate:
+And if you're reading this as a contributor, user, or future teammate:  
 this handbook is our attempt to show how we think, not just what we build.
 
 That feels like the right place to start.