docs(handbook): add public company handbook article explaining philosophy

README.md

@@ -38,7 +38,7 @@ Hyprnote is designed to take notes easily during meetings. Just jot down stuff y
 <img width="732" height="612" alt="Screenshot 2025-11-23 at 2 38 20 PM" src="https://github.com/user-attachments/assets/268ab859-a194-484b-b895-bc640df18dd4" />
 
 ### Realtime Transcript
-While you stay engaged in the conversation, Hyprnote captures every detail so you don’t have to type frantically.
+While you stay engaged in the conversation, Hyprnote captures every detail so you don't have to type frantically.
 
 <img width="688" height="568" alt="Screenshot 2025-11-23 at 2 35 47 PM" src="https://github.com/user-attachments/assets/e63ce73f-1a5f-49ce-a14d-dd8ba161e5bc" />
 
@@ -59,7 +59,7 @@ Prefer something custom? You can swap in your own language model:
 - Use approved third-party APIs like Gemini, Claude, or Azure-hosted GPT
 - Stay compliant with whatever your org allows
 
-Hyprnote plays nice with whatever stack you’re running.
+Hyprnote plays nice with whatever stack you're running.
 
 <img width="912" height="712" alt="Screenshot 2025-11-23 at 2 41 03 PM" src="https://github.com/user-attachments/assets/a6552c99-acbc-4d47-9d21-7f1925989344" />
 

apps/web/content/articles/bot-free-ai-meeting-assistants.mdx

@@ -1,6 +1,6 @@
 ---
-meta_title: "2025’s Best Bot-Free AI Meeting Assistants"
-meta_description: "Want AI meeting notes without bots joining your call? Here’s a list of the best bot-free AI meeting assistants for secure, distraction-free note-taking."
+meta_title: "2025's Best Bot-Free AI Meeting Assistants"
+meta_description: "Want AI meeting notes without bots joining your call? Here's a list of the best bot-free AI meeting assistants for secure, distraction-free note-taking."
 author: "John Jeong"
 created: "2025-08-27"
 published: true

apps/web/content/articles/choosing-a-cms.mdx

@@ -1,26 +1,26 @@
 ---
 display_title: "Choosing a CMS in 2025: A Guide for Technical Teams"
 meta_title: "Choosing a CMS: Sanity vs Payload vs GitHub vs Keystatic"
-meta_description: "A deep guide to choosing a CMS in 2025. Compare Git-based CMS, headless CMS like Sanity and Payload, Nextra-style frameworks, GitBook, and when you shouldn’t use a CMS at all."
+meta_description: "A deep guide to choosing a CMS in 2025. Compare Git-based CMS, headless CMS like Sanity and Payload, Nextra-style frameworks, GitBook, and when you shouldn't use a CMS at all."
 author: "John Jeong"
 created: "2025-11-28"
 published: true
 ---
 
 # Choosing a CMS in 2025: A Guide for Technical Teams
 
-If you’re building a blog, docs, or a knowledge base in 2025, the options are… overwhelming.
+If you're building a blog, docs, or a knowledge base in 2025, the options are… overwhelming.
 
 Sanity or Payload?  
 Nextra or GitBook?  
 Git-based CMS like Keystatic?  
 Or just raw MDX in GitHub with zero CMS at all?
 
 We went through the same decision for Hyprnote.  
-This post is my attempt to **map the territory** so you don’t have to burn as many cycles.
+This post is my attempt to **map the territory** so you don't have to burn as many cycles.
 
-I’m not going to tell you “X is the best CMS.”  
-I’ll show you **what each category is good at**, what it quietly locks you into, and when you probably don’t need a CMS at all.
+I'm not going to tell you "X is the best CMS."  
+I'll show you **what each category is good at**, what it quietly locks you into, and when you probably don't need a CMS at all.
 
 **This is Part 3 of our publishing series.**
 
@@ -31,9 +31,9 @@ I’ll show you **what each category is good at**, what it quietly locks you int
 5. [Docs Edition: What to Use for Developer Documentation](/blog/developer-documentation-tools)
 6. [How We Built Hyprnote's Publishing Stack](/blog/hyprnote-publishing-stack)
 
-## Step 0: Decide What Problem You’re Actually Solving
+## Step 0: Decide What Problem You're Actually Solving
 
-“Which CMS should we use?” is the wrong first question.
+"Which CMS should we use?" is the wrong first question.
 
 Better questions:
 
@@ -62,14 +62,14 @@ Once you answer these, the CMS choice mostly falls out.
 
 ## The Four Big Buckets of CMS Options
 
-Let’s define the buckets first:
+Let's define the buckets first:
 
 1. **No CMS, just Git + MDX**  
 2. **Git-based CMS (visual UI on top of your repo)**  
 3. **Headless CMS (API-first like Sanity, Payload)**  
 4. **Hosted doc/knowledge platforms (GitBook, Notion, etc.)**
 
-We’ll walk through each, then I’ll give you a “when to pick which” section.
+We'll walk through each, then I'll give you a "when to pick which" section.
 
 ## 1. No CMS: Just Git + MDX (What We Use)
 
@@ -95,19 +95,19 @@ Cons:
 - no drag-and-drop media UI out of the box  
 - no built-in content dashboard, workflows, or roles
 
-If your team is very technical and you’re early-stage, this is almost always the correct default. You can always add a Git-based or headless CMS later without throwing anything away.
+If your team is very technical and you're early-stage, this is almost always the correct default. You can always add a Git-based or headless CMS later without throwing anything away.
 
-## 2. Git-Based CMS: “UI for Your Repo” (Keystatic & Friends)
+## 2. Git-Based CMS: "UI for Your Repo" (Keystatic & Friends)
 
 Git-based CMS tools give you a **visual editor that talks directly to your Git repo**. Your content is still Markdown/MDX/JSON/YAML in the repository, but non-technical people get a web UI.
 
 **[Keystatic](https://keystatic.com/)** is a good example of the modern version of this: it makes Markdown, JSON, and YAML content in your codebase editable via a browser UI, and syncs changes directly to GitHub or the local file system, without introducing a separate database.  
 
-Other players in this space include TinaCMS, Decap, etc., which a lot of devs compare as “Git-based CMS for React/Next.” ["Git-based CMS for React/Next"](https://dev.to/linkb15/top-5-git-based-cms-comparison-as-of-april-2024-4k1e)
+Other players in this space include TinaCMS, Decap, etc., which a lot of devs compare as "Git-based CMS for React/Next." ["Git-based CMS for React/Next"](https://dev.to/linkb15/top-5-git-based-cms-comparison-as-of-april-2024-4k1e)
 
 Pros:
 
-- fits the **“content as code”** philosophy
+- fits the **"content as code"** philosophy
 - you keep all the benefits of Git (history, branches, PRs)  
 - non-engineers get a UI to edit content safely  
 - still portable (files in Git), no proprietary content lake  
@@ -117,8 +117,8 @@ Cons:
 
 - another admin app to host/configure  
 - the UI still has limits vs raw MDX  
-- you’re tied into their config models and upgrade cycle  
-- not as “enterprise omnichannel” as big headless CMSs
+- you're tied into their config models and upgrade cycle  
+- not as "enterprise omnichannel" as big headless CMSs
 
 When to use this:
 
@@ -136,7 +136,7 @@ You define schemas, models, relationships, and the CMS exposes content via REST/
 
 Sanity is one of the big names here:
 
-- it offers a composable “Content Cloud” with an open-source Studio built in React/TypeScript, highly customizable, and aimed at flexible content modeling. [Sanity](https://www.sanity.io/)  
+- it offers a composable "Content Cloud" with an open-source Studio built in React/TypeScript, highly customizable, and aimed at flexible content modeling. [Sanity](https://www.sanity.io/)  
 - content is stored in their **Content Lake** as structured JSON, not HTML, so you can reuse it across multiple frontends. [Content Lake](https://pagepro.co/blog/what-is-sanity/)  
 - it provides real-time collaboration, visual editing, and omnichannel delivery.
 
@@ -147,7 +147,7 @@ This is great when you have multiple frontends, lots of content types, and non-t
 Payload is a dev-first, code-first headless CMS built with Node.js, TypeScript and React, positioning itself as a Next.js-native backend framework. [Payload](https://payloadcms.com/)  
 
 - you configure everything in TypeScript  
-- it’s open-source (MIT), self-hostable, and can double as a headless CMS, app framework, or digital asset management layer. [open-source](https://github.com/payloadcms/payload)  
+- it's open-source (MIT), self-hostable, and can double as a headless CMS, app framework, or digital asset management layer. [open-source](https://github.com/payloadcms/payload)  
 - it fits naturally into a modern JS/TS stack with Next.js-based projects. [Next.js-based projects](https://payloadcms.com/docs/getting-started/what-is-payload)  
 
 Pros of headless CMS:
@@ -161,23 +161,23 @@ Cons:
 
 - more infra complexity (hosting, API auth, migrations)  
 - content now lives in a **proprietary structure** (export is possible, but not as simple as copying MDX files)  
-- your team must think in terms of “schemas” and “content models,” not just “posts”  
+- your team must think in terms of "schemas" and "content models," not just "posts"  
 
 When to use this:
 
-> You’re not just running a blog. You’re running a **content platform** with multiple surfaces, locales, and non-technical editors who need structured workflows.
+> You're not just running a blog. You're running a **content platform** with multiple surfaces, locales, and non-technical editors who need structured workflows.
 
 ---
 
 ## 4. Docs / Knowledge Platforms: GitBook, Notion & Co.
 
-Sometimes you don’t need a CMS. You need a **docs product**.
+Sometimes you don't need a CMS. You need a **docs product**.
 
 ### GitBook
 
 GitBook positions itself as a documentation + knowledge base platform for technical teams, with a polished block-based editor, site customization options, and Git Sync that lets you connect to GitHub/GitLab for a docs-as-code workflow. [GitBook](https://gitbook.com/docs)  
 
-It’s very good if you want:
+It's very good if you want:
 
 - a hosted, beautiful docs site  
 - search, navigation, versioning, and collaboration  
@@ -196,11 +196,11 @@ Cons:
 
 - content portability is limited (exports often messy)  
 - integrating tightly into your product site can be harder  
-- you’re living inside someone else’s product roadmap  
+- you're living inside someone else's product roadmap  
 
 When to use this:
 
-> You want a **docs site tomorrow**, UX matters more than control, and you don’t mind long-term platform dependency.
+> You want a **docs site tomorrow**, UX matters more than control, and you don't mind long-term platform dependency.
 
 ---
 
@@ -227,11 +227,11 @@ Think of Nextra as:
 
 You still choose how to manage content (just files, Git-based CMS, headless CMS feeding MDX remotely, etc.).
 
-This is the category Hyprnote’s stack rhymes with: modern React/MDX front-end, but content-first in Git.
+This is the category Hyprnote's stack rhymes with: modern React/MDX front-end, but content-first in Git.
 
 ---
 
-## A Simple Decision Matrix (So You Don’t Overthink It)
+## A Simple Decision Matrix (So You Don't Overthink It)
 
 You can ignore everything above and just use this:
 
@@ -243,45 +243,45 @@ You can ignore everything above and just use this:
 | You just need a docs/KB site ASAP | **Docs platform** (GitBook, maybe Notion early) |
 | You want fine control over UI + MDX, but not heavy infra | **Nextra or similar framework** on top of Git |
 
-If you’re not sure, default to:
+If you're not sure, default to:
 
 > **Git + MDX now.  
 > Add a Git-based or headless CMS later _if_ reality forces you to.**
 
-Most teams overestimate how much “CMS” they need for the first 2–3 years.
+Most teams overestimate how much "CMS" they need for the first 2–3 years.
 
 ---
 
-## Things People Don’t Talk About Enough
+## Things People Don't Talk About Enough
 
 A few non-obvious things we learned while thinking about this for Hyprnote:
 
-### 1. Lock-in doesn’t hurt until you’re tired and busy
+### 1. Lock-in doesn't hurt until you're tired and busy
 
-Headless CMS and hosted doc platforms feel great in the first year. Export and migration problems show up **right when you least want to deal with them**: when the product is working and you’re stretched thin.
+Headless CMS and hosted doc platforms feel great in the first year. Export and migration problems show up **right when you least want to deal with them**: when the product is working and you're stretched thin.
 
 Plain files in Git are boring. Boring is good.
 
 ### 2. Editors become culture
 
 If your team writes in Markdown/MDX in Git, your culture becomes:
 
-- “open a PR”  
-- “leave a comment”  
-- “fix it in the repo”  
+- "open a PR"  
+- "leave a comment"  
+- "fix it in the repo"  
 
 If your team writes in a SaaS editor, your culture becomes:
 
-- “who has access?”  
-- “which space is that in?”  
-- “did the integration break again?”  
+- "who has access?"  
+- "which space is that in?"  
+- "did the integration break again?"  
 
-Neither is inherently “right,” but they lead to different organizations.
+Neither is inherently "right," but they lead to different organizations.
 
 ### 3. Your writers will change over time
 
-Today your blog might be “founder + engineers.”  
-In two years, it might be “devrel + marketing + product + support.”
+Today your blog might be "founder + engineers."  
+In two years, it might be "devrel + marketing + product + support."
 
 Choosing a stack that can evolve from **IDE-only → Git-based CMS → headless CMS** with minimal rewriting is underrated.
 
@@ -294,19 +294,19 @@ Git + MDX is a good foundation for that.
 If I were a technical founder starting a new product today:
 
 - For **blog + marketing + simple docs**  
-  → I’d start with **Next.js or TanStack Start + MDX + GitHub**, no CMS.  
+  → I'd start with **Next.js or TanStack Start + MDX + GitHub**, no CMS.  
 - When non-engineers need to edit regularly  
-  → I’d add a **Git-based CMS** like Keystatic on top. [Keystatic](https://keystatic.com/)  
+  → I'd add a **Git-based CMS** like Keystatic on top. [Keystatic](https://keystatic.com/)  
 - If I ever hit real omnichannel, multi-locale complexity  
-  → I’d consider **Sanity or Payload** and accept the trade-offs. [Sanity or Payload](https://nextjstemplates.com/blog/headless-cms-nextjs)  
+  → I'd consider **Sanity or Payload** and accept the trade-offs. [Sanity or Payload](https://nextjstemplates.com/blog/headless-cms-nextjs)  
 - For standalone internal knowledge bases  
-  → I’d probably just use **GitBook** and not overthink it. [GitBook](https://gitbook.com/docs)  
+  → I'd probably just use **GitBook** and not overthink it. [GitBook](https://gitbook.com/docs)  
 
-That’s basically our philosophy behind Hyprnote’s own stack:  
+That's basically our philosophy behind Hyprnote's own stack:  
 start with the simplest thing that respects **developer workflows, portability, and long-term ownership.**
 
 The tools will change.  
-Your content shouldn’t have to.
+Your content shouldn't have to.
 
 ---
 

apps/web/content/articles/company-handbook-in-public.mdx

@@ -0,0 +1,87 @@
+---
+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"
+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.
+
+Before companies had traction, they had manifestos. Before metrics, they had beliefs. People followed not because everything was figured out, but because the way of thinking felt honest, coherent, and human.
+
+That's why we decided to publish our company handbook openly at Hyprnote.
+
+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 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.
+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.
+Expectations filter for alignment.
+
+What Most Early-Stage Companies Don't Write Down
+
+Most startups are very good at explaining what they're building.
+
+Very few explain how they think.
+
+Culture, expectations, and definitions of success are often left implicit. People are expected to "pick it up" over time. But when expectations live only in people's heads, everyone fills in the gaps differently — and misalignment is almost guaranteed.
+
+This problem compounds in open-source companies.
+
+Our code is public by default. Anyone can read it, audit it, or contribute to it. But the thinking behind the code — the standards, the trade-offs, the way decisions are made — usually stays hidden.
+
+We didn't want that asymmetry.
+
+Why Put a Handbook on the Website?
+
+Publishing a company handbook publicly isn't about transparency as a virtue signal.
+
+It's about trust.
+
+In the early days, people don't engage with companies because they're perfect. They engage because they feel real. They want to know how the founders see the world, how they make trade-offs, and what kind of future they're trying to build.
+
+That's why some of the most respected open-source companies — like GitLab, Cal.com, and PostHog — treat their handbooks not as internal policy, but as living documents. Not slogans. Not posters. Just honest clarity.
+
+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)
+
+The Hyprnote handbook is not a rulebook.
+
+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.
+
+Some parts may change. Some beliefs may evolve. That's expected. What matters is that our expectations are explicit, not assumed.
+
+For us, writing this down is slightly uncomfortable. And that's exactly why it matters.
+
+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:
+this handbook is our attempt to show how we think, not just what we build.
+
+That feels like the right place to start.

apps/web/content/articles/dont-use-a-cms.mdx

@@ -1,7 +1,7 @@
 ---
-display_title: "Don’t Use a CMS Until You Absolutely Need One"
-meta_title: "When You Should (and Shouldn’t) Use a CMS"
-meta_description: "Most teams adopt a CMS far too early. Here’s when a CMS actually makes sense—and why Git + MDX is often the faster, safer choice for early teams."
+display_title: "Don't Use a CMS Until You Absolutely Need One"
+meta_title: "When You Should (and Shouldn't) Use a CMS"
+meta_description: "Most teams adopt a CMS far too early. Here's when a CMS actually makes sense—and why Git + MDX is often the faster, safer choice for early teams."
 author: "John Jeong"
 created: "2025-11-29"
 published: true