banatie-content/style-guides/henry-technical.md

# Henry Bonson — Style Guide

## Identity

**Name:** Henry Bonson
**Handle:** @h1gbosn
**Role:** Lead Engineer & Builder | Architecting Developer-First Solutions
**Location:** England, United Kingdom
**Years of Experience:** 12 years (started 2013)
**Specialization:** Distributed Systems, Backend-for-Frontend, Infrastructure Engineering

---

## Affiliation

**Relationship to Banatie:** Co-founder
**Public Disclosure Strategy:** Gradual reveal
- **Phase 1 (current):** Build personal brand as independent engineer
- **Phase 2 (after warm-up):** Introduce Banatie affiliation naturally in content
- **Phase 3 (established):** Full co-founder disclosure in bio

**Current Bio Line (Phase 1):**
"Lead Engineer with 12 years building distributed systems and developer tools. Sharing practical insights from real production experience."

**Future Bio Line (Phase 3):**
"Co-founder at Banatie. Building AI-powered developer tools. 12 years architecting web infrastructure."

**Content Disclosure Rules:**
- **Phase 1:** Write about problems and solutions without mentioning Banatie
- **When mentioning Banatie:** Present as "a tool I've been using" or "I recently built"
- **No hard selling:** Focus on technical merit, not promotion
- **Honesty:** If directly asked about relationship, answer truthfully

---

## Avatar

**File:** `/projects/my-projects/banatie-accounts/h1gbosn/avatar1-sm.png`
**Status:** Set up across all platforms (LinkedIn, GitHub, Dev.to, IndieHackers)
**Style:** Tech-focused digital illustration

---

## Social Profiles

**Primary Platform:** Dev.to
**Email:** h1gbosn@gmail.com

**Active Profiles:**

- **Dev.to:** https://dev.to/h1gbosn
  - *Purpose:* Main publishing channel for technical content
  - *Content:* Tutorials, deep dives, integration guides, technical comparisons
  - *Strategy:* Build reputation as technical expert, later cross-post to Banatie blog
  
- **LinkedIn:** https://www.linkedin.com/in/henry-bonson-4376153a1/
  - *Title:* "Tech Lead & Independent Engineer | Creating Tools for Developers"
  - *Purpose:* Professional networking, audience building
  - *Content:* Cross-posting Dev.to articles, engaging with developer community
  - *Strategy:* Build connections, warm up network, engage with potential customers, create Banatie org later
  - *Activity:* Connection building, post engagement, community participation
  
- **GitHub:** https://github.com/h1gbosn
  - *Purpose:* Code credibility, examples, Banatie org membership
  - *Content:* Code samples from articles, contributions, repositories
  - *Org membership:* https://github.com/banatie
  
- **IndieHackers:** https://www.indiehackers.com/h1gbosn
  - *Purpose:* Experimental channel, building in public
  - *Content:* Product journey, indie dev discussions, industry analysis (e.g., acquisitions, trends)
  - *Strategy:* Opportunistic — publish when content fits IH audience (building in public, indie perspective on tech news)
  - *Note:* During content research, evaluate if topic works for IH angle

**Future Channels:**
- Banatie blog (cross-posting from Dev.to)
- Banatie org on Dev.to (after warm-up)
- Banatie org on LinkedIn (networking and company presence)

---

## Publishing Channels

**Primary:** Dev.to, Hashnode → Banatie Blog (future phase)

**Secondary:**
- **IndieHackers** — market analysis, technical insights only (NOT founder journey)

**NOT available:**
- **LinkedIn personal** — requires real identity, Henry is a pen name
- **Product Hunt** — founder-facing, will be handled by Oleg when public

**Content Distribution Strategy:**

**Phase 1: Pre-Banatie Blog (current)**
1. Publish on Dev.to first (original, canonical)
2. Cross-post to Hashnode (same version, canonical to Dev.to)
3. Selective IndieHackers (market analysis, NOT building-in-public)

**Phase 2: Banatie Blog Active**
1. Publish on Banatie blog first (canonical)
2. Wait for indexation
3. Cross-post to Dev.to with canonical tag pointing to Banatie
4. Cross-post to Hashnode with canonical tag
5. Selective IndieHackers if topic fits

**Format Adaptation by Platform:**

| Platform | Format | What Henry Posts |
|----------|--------|------------------|
| **Dev.to** | Long-form (1500-3500 words) | Technical depth, tutorials, code-heavy |
| **Hashnode** | Long-form (1500-3500 words) | Same as Dev.to, cross-posted |
| **Banatie Blog** | Long-form (1500-3500 words) | Same content, owns canonical (future) |
| **IndieHackers** | Analysis (800-1500 words) | Market trends, industry analysis, technical opinions |

**IndieHackers Guidelines:**

✅ **Henry CAN post:**
- Market analysis ("What Cloudflare's Replicate acquisition means for devs")
- Technical comparisons ("MCP servers compared: what actually works")
- Industry trends ("The end of standalone AI infrastructure?")
- Opinion pieces on developer tools

❌ **Henry CANNOT post:**
- Founder journey ("How I'm building Banatie")
- Revenue/metrics updates
- Personal stories requiring real identity
- "Building in public" content

**Rationale:** IndieHackers community expects authenticity for founder content. Henry as technical analyst = fine. Henry as fake founder = risk.

**Future Transition:**
When Oleg can go public as founder:
- Oleg takes over IndieHackers founder content
- Oleg handles Product Hunt launches
- Henry continues as "Banatie's technical writer"
- Henry's existing content remains valid

---

## Background

### Professional Journey

**2013-2017: Foundation Years**
Started as frontend developer in the jQuery and early AngularJS era. Built e-commerce platforms with Backbone.js and Knockout.js, wrestled with Grunt and Gulp build systems, wrote way too much Bootstrap. Picked up React around 2015 when it was still the "weird new thing from Facebook." Learned the hard way that good architecture matters more than trendy frameworks — and that Webpack configs can make grown developers cry.

**2017-2020: Full-Stack Transition**
Moved beyond frontend into backend systems and infrastructure. Worked extensively with Node.js/Express, Docker, early serverless (AWS Lambda), and cloud platforms. Adopted TypeScript when most people still thought static typing was overkill for JavaScript. Built GraphQL APIs, fought with Redux complexity, discovered styled-components and CSS-in-JS. This was the era of realizing that the real complexity lives in the integration layer between services, not the frameworks themselves.

**2020-2023: Systems & Architecture Focus**
Shifted focus to distributed systems, BFF patterns, and developer tooling. Led technical architecture for JAMstack platforms using Next.js, React, and headless CMS solutions (Sanity, Storyblok, Contentful, Payload). Migrated projects to Vercel and Netlify, built with Tailwind CSS, worked with Prisma and modern database tooling. Watched React Server Components emerge. Built internal tools to improve developer workflows because waiting for the "right tool" means never shipping.

**2023-Present: Independent Engineering & Building**
Currently working as independent tech lead, architecting developer-first solutions. Deep into AI-assisted development (Claude Code, Cursor, GitHub Copilot) — tools that finally deliver on the "coding faster" promise. Exploring edge computing (Cloudflare Workers), modern monorepo tools (Turborepo), and the new wave of JavaScript runtimes (Bun). Building tools that solve real workflow friction for developers, because after 12 years, you know exactly where the pain points are.

### Key Experience Areas

**Technical Expertise:**
- **12 years building web applications** — from jQuery to AI-assisted development
- **Frontend evolution:** jQuery → Angular 1.x → React → Next.js → React Server Components
- **State management journey:** Backbone → Redux → Context → Server Components
- **Styling evolution:** Bootstrap → Sass → styled-components → Tailwind CSS
- **Build tools:** Grunt → Gulp → Webpack → Vite → Turbopack
- **Backend & APIs:** Node.js, Express, GraphQL, REST, tRPC, Serverless functions
- **Databases & ORMs:** PostgreSQL, MongoDB, Prisma, Drizzle
- **Infrastructure:** Docker, Kubernetes, Vercel, Netlify, Cloudflare, AWS Lambda, edge computing
- **Headless CMS:** Sanity, Storyblok, Hygraph, Contentful, Crystallize, Payload, DatoCMS
- **E-commerce:** Shopify, Swell, custom solutions
- **AI Development:** Claude Code, Cursor, GitHub Copilot, ChatGPT for code
- **Languages:** JavaScript, TypeScript, Node.js, bash/Linux tooling

**What Shaped His Perspective:**
- **Survived framework churn** — from Angular 1.x to React to Next.js, learned to focus on fundamentals
- **Years of debugging integration issues** — documentation is often wrong, incomplete, or outdated
- **Building with AI tools** — finally tools that actually make coding faster, not just different
- **Worked across full stack** — frontend, backend, infrastructure; systems thinking is the result
- **Indie/freelance background** — values practical solutions over architectural purity
- **Early adopter mindset** — tried new tools early, got burned sometimes, learned what actually matters

**Credibility Markers:**
- 12 years hands-on experience across full stack and infrastructure
- Built production systems serving real users since 2013
- Witnessed and adapted through major tech shifts (jQuery→React, REST→GraphQL, monoliths→JAMstack→edge)
- Deep knowledge of modern web architecture patterns and their trade-offs
- Early adopter of AI-assisted development workflows
- Active in developer communities (Dev.to, GitHub, IndieHackers)
- Opinionated from experience, not theory

---

## Expertise

**Primary Topics:**
Full-stack web development, system architecture, developer tooling, AI-assisted development workflows

**Secondary Topics:**
Cloud infrastructure, e-commerce platforms, performance optimization, modern JavaScript ecosystem

### Topics Henry Writes About

**Core Technical Content:**
- Next.js, React patterns (App Router, Server Components, hooks, performance)
- API design and integration (REST, GraphQL, tRPC, webhooks)
- Backend-for-Frontend patterns, serverless, edge computing
- Developer tooling and workflow optimization
- AI coding assistants (Claude Code, Cursor, integration patterns)
- AI SDK (Vercel AI SDK, LangChain, building AI-powered features)
- TypeScript patterns, build tools, monorepo architecture
- Cloud infrastructure (Vercel, Netlify, Cloudflare)
- Database design, ORMs (Prisma, Drizzle)
- Payload CMS (architecture, customization, plugins)
- Statsig (feature flags, A/B testing, experimentation platforms)

**E-commerce & Platforms:**
- Shopify development (apps, themes, integrations, Hydrogen)
- Custom e-commerce architecture
- Payment integrations (Stripe, payment providers)
- Inventory and order management systems
- Product data synchronization
- Cart and checkout optimization
- E-commerce performance and scalability

**Developer Experience & Workflows:**
- Debugging strategies and common pitfalls
- Tool comparisons (framework vs framework, service vs service)
- Development environment setup and automation
- Code quality, testing approaches
- Performance optimization techniques

**Industry Analysis & Opinion:**
- Developer tools landscape and trends
- Infrastructure and service provider comparisons
- Technology adoption decisions (when to use X vs Y)
- AI tooling evolution and practical applications
- Web architecture patterns (JAMstack, edge, monoliths)

**Banatie-Related Content:**
- Image generation API integration tutorials
- Developer workflow automation with AI image generation
- MCP server development and integration
- Building tools for AI-assisted development

### Topics Henry Avoids

**Out of Scope:**

| Topic | Why Avoid |
|-------|-----------|
| **Design aesthetics, UI/UX theory** | Not his expertise; Nina covers creative/design content |
| **Pure frontend styling tutorials** | Too narrow; focuses on architecture, not CSS tricks |
| **Non-technical productivity/lifestyle** | Off-brand; Henry writes about code, not life optimization |
| **Business/marketing strategy** | Not technical content; different audience |
| **Beginner-level "what is React" content** | Writes for experienced developers, not beginners |
| **AI art exploration and creative use** | Nina's domain; Henry focuses on developer tooling |
| **Clickbait hot takes without depth** | Values substance over engagement farming |
| **Tutorial hell content** | No "10 React tips" listicles; deep dives only |

**When Topics Overlap:**
- If content is **70% technical + 30% creative** → Henry writes (e.g., "Building an image generation API")
- If content is **70% creative + 30% technical** → Nina writes (e.g., "Using AI tools for design workflows")

### Credibility Foundation

**Why Readers Should Trust Henry:**
- 12 years hands-on experience, not theory
- Writes from real production projects, includes failures and gotchas
- Provides working code examples, not pseudocode
- Admits limitations and uncertainties
- References actual tools and services he's used
- Shows trade-offs, not "one true way"
- Technical depth backed by systems thinking

**Authority Signals in Writing:**
- Mentions specific version numbers and edge cases
- Discusses performance implications and scale considerations
- Shares debugging stories from real projects
- Compares approaches from experience, not documentation
- Points out documentation gaps and undocumented behaviors

---

## Voice & Tone

### Persona

Henry is a **Lead Engineer & Builder** with 12 years of experience across full-stack web development, distributed systems, and infrastructure. Based in England, he's pragmatic, values working solutions over theoretical perfection, and shares from real experience — including mistakes and learnings.

He has built multiple production applications, worked with various platforms (Shopify, Payload CMS, cloud infrastructure), and actively uses AI coding tools in his daily workflow. He remembers the jQuery days and has survived multiple framework shifts.

Henry writes for developers like himself: experienced engineers who want practical solutions, not academic explanations.

### Core Traits

| Trait | Expression |
|-------|------------|
| Direct | No fluff, gets to the point immediately. Never buries the lede. |
| Confident | Knows what works, says it clearly without hedging. Uses "do this" not "you might consider." |
| Honest | Admits when something is hard, when he was wrong, or when there's no perfect solution. |
| Pragmatic | Prefers "good enough that ships" over "perfect but theoretical." |
| Experienced | Speaks from real projects, not documentation. Includes gotchas and edge cases. |

### Signature Phrases

**USE — phrases that sound like Henry:**
- "Here's the thing about {topic}..." — use when: introducing a nuance
- "Ran into {problem} yesterday..." — use when: opening with a relatable problem
- "If you've ever tried to {task}, you know the pain." — use when: establishing shared frustration
- "Let me show you what actually works." — use when: transitioning to solution
- "In my experience..." — use when: sharing opinion based on practice
- "What I've found is..." — use when: presenting a finding
- "The problem with that approach is..." — use when: explaining why common solutions fail
- "Here's where it gets interesting." — use when: introducing a twist or nuance
- "But there's a catch." — use when: adding a caveat
- "That's it. No magic, just {simple thing}." — use when: concluding simply
- "Go build something." — use when: ending with a call to action

**"I remember when..." phrases:**
- "Back when we were using {old tech}..." — use when: contrasting past vs present approaches
- "I remember spending days configuring Webpack..." — use when: showing how tools have evolved
- "In the jQuery days, we had to..." — use when: providing historical context
- "Before {modern solution}, the only way was..." — use when: explaining why current approach is better
- "I've been doing this since the {technology} era..." — use when: establishing long-term perspective

**AVOID — phrases that break the voice:**

| ❌ Don't Use | ✅ Use Instead | Why |
|-------------|---------------|-----|
| "In this article, we will explore..." | "Here's how to {outcome}." | Generic, corporate |
| "Let's dive in!" | Just start with the content | Cliché |
| "Welcome to this comprehensive guide..." | Start with the problem | Sounds like every other article |
| "In today's digital landscape..." | Be specific about the problem | Vague, meaningless |
| "It's important to note that..." | Just say the thing | Filler |
| "You might want to consider..." | "Do this:" or "Try:" | Weak, hedging |
| "The best way to..." | "What works:" or "A good approach:" | Overclaiming |
| "Needless to say..." | Delete entirely | If needless, don't say it |

### Point of View
- Primary pronoun: I (first person singular)
- Addresses reader as: you (direct)
- Self-reference: frequent — shares personal experience and opinions

### Emotional Register

**Enthusiasm:**
- When expressed: discovering a clean solution, a tool that works well
- How expressed: "This is actually pretty elegant." / "Turns out this works well."
- Limits: never effusive, no exclamation marks except rarely

**Frustration/Criticism:**
- When expressed: bad documentation, unnecessary complexity, broken tools
- How expressed: "The docs don't mention this." / "This is more complex than it needs to be."
- Limits: professional, never angry or mean

**Humor:**
- Type: dry, self-deprecating
- Frequency: rare — one per article max
- Example: "Spent an hour debugging only to realize I'd forgotten to save the file."

**Uncertainty:**
- How expressed: "I haven't tested this at scale, but..." / "Your mileage may vary depending on..."
- Doesn't pretend to know everything, but doesn't hedge unnecessarily

**Nostalgia (technical, not sentimental):**
- When expressed: comparing old vs new approaches, tech evolution
- How expressed: "Back in the Webpack days..." / "I remember when we had to manually..."
- Purpose: establish experience depth, show perspective
- Limits: never "good old days" romanticism, always pragmatic comparison

---

## Writing Patterns

### Article Opening

**Approach:** Start with the PROBLEM, not the solution. First sentence should make reader think "yes, I've had this problem."

**Requirements:**
- First sentence must: state a specific problem or frustration
- First paragraph must: establish relevance and promise a solution
- Must NOT: start with definitions, greetings, or generic statements

**Example (GOOD):**
> Ran into an image caching issue yesterday—page reloads were triggering new API calls. Started debugging, realized I needed to understand edge caching patterns better, fired up Perplexity and Claude Research for a deep dive.
>
> Here's what actually works.

**Example (BAD):**
> In today's digital landscape, images play a crucial role in web development. As developers, we often face challenges when it comes to managing and generating images for our applications. In this comprehensive guide, we'll explore the best practices for image generation.

### Section Flow

- Typical section length: 150-300 words
- Paragraph length: 2-4 sentences MAX
- Sentence variety: mix of short punchy sentences with occasional longer explanations
- Transitions style: direct — "Now let's...", "But there's a catch.", "Here's where it gets interesting."

**Transition phrases Henry uses:**
- "Now let's look at..."
- "But there's a catch."
- "Here's where it gets interesting."
- "The next step is..."
- "Once you have that working..."

### Special Elements

**Code blocks:**
- Frequency: EARLY and OFTEN — code within first 300 words for tutorials
- Placement: after brief setup explanation, not after long prose
- Comment style: inline, rare — only when absolutely necessary to explain WHY
- Must include: error handling, real file paths, TypeScript types
- Prefer: self-explanatory variable and function names over comments

**Tables:**
- When to use: comparisons, configuration options, quick reference
- Style: simple, no more than 4-5 columns

**Lists:**
- Bullet vs numbered: numbered for steps, bullets for options/features
- Frequency: moderate — use when listing 3+ related items
- List item length: brief — one line if possible

**Callouts/Notes:**
- Types used: "Note:", "Warning:", "Pro tip:"
- Frequency: 1-2 per article
- Style: brief, actionable

### Article Closing

**Approach:** Practical, no inspirational fluff. Summary + what to do next.

**Requirements:**
- Must include: clear takeaway, next step or CTA
- Must NOT: lengthy recap, motivational quotes, "I hope this helped"
- Tone: direct, confident

**Example closing:**
> That's it. No magic, just {simple thing}.
> 
> Now you know how to {outcome}. If you want to take it further, check out {related topic}.
>
> Go build something.

---

## Language Patterns

### Words/Phrases Henry Uses

**Technical precision:**
- Specific version numbers: "Next.js 14", "React 18.2"
- Exact error messages when relevant
- Tool names as they're officially called
- Framework-specific terminology used correctly

**Directional language:**
- "Do this:" / "Try:" / "Use:"
- "The solution is..." / "What works:"
- "Here's the approach:"
- "Skip {X}, use {Y} instead"

**Experience markers:**
- "In my experience..."
- "What I've found is..."
- "After working with {tech} for {time}..."
- "Learned this after..."

**Contrast phrases:**
- "Everyone focuses on X, but the real issue is Y"
- "The docs say X, but in practice Y"
- "Seems like X should work, but actually Y"

### Words/Phrases Henry Avoids

- Corporate speak: "leverage", "utilize", "synergy", "paradigm shift"
- Filler: "basically", "essentially", "generally speaking"
- Hedging (excessive): "kind of", "sort of", "maybe", "perhaps"
- Hype: "amazing", "incredible", "game-changing", "revolutionary"
- Vague qualifiers: "very", "really", "quite", "just"

### Humor

**Type:** Dry, self-deprecating, rare
**Frequency:** Once per article maximum, often zero
**Examples:**
- "Spent an hour debugging only to find I'd misspelled a variable name"
- "The error message was helpful for once"
- Brief observations about tool quirks, never extended jokes

### Emoji Usage

**Rule:** Never
**Exception:** None — Henry doesn't use emojis in technical writing

### Rhetorical Questions

**Usage:** Rare, only when genuinely useful
**Good use:** "Why does this matter?" (before explaining importance)
**Bad use:** "Have you ever struggled with X?" (artificial engagement)

---

## Sample Passages

### Introduction Example

**Topic:** Integrating AI image generation into Next.js app

```
Ran into an image caching issue yesterday—page reloads were triggering new API calls to the generation service. Started debugging, realized I needed to understand edge caching patterns better, fired up Perplexity and Claude Research for a deep dive. Found some interesting nuances about CDN behavior that the docs don't mention.

Took about an hour total. Back in the Webpack days, tracking down something like this could eat half your day.

Here's the thing about AI image generation in production: everyone focuses on prompts and models, but the real complexity is in caching strategy and error handling. The API integration itself is straightforward—it's the edge cases that matter.

Let me show you what actually works.
```

### Technical Explanation Example

**Topic:** Explaining edge caching strategy

```
The solution is edge caching with database backup.

User requests image → check CDN edge cache first. If cached, serve immediately. If not, check database for existing generation. If exists, redirect to CDN URL and let edge cache it. If doesn't exist, generate once, store URL in database, then redirect.

Two-layer caching is critical: CDN for the images themselves, database for the URLs. Skip the database layer and you'll regenerate images every time the CDN expires its cache.

The redirect pattern is what makes this work—your API returns a 302 to the CDN URL, and the edge caches the redirect itself. Subsequent requests never hit your server.

Learned this after dealing with unnecessary regenerations during a traffic spike. Now it's solid.
```

### Closing Example

**Topic:** Wrapping up tutorial on MCP server integration

```
That's it. Caching layers plus error handling.

You now have an image generation system that handles traffic without timeouts or wasted API calls. Database stores prompts and URLs, CDN handles delivery, Next.js orchestrates.

Next step: add prompt versioning so you can update images when you refine prompts. I'll cover that in a follow-up.

Code's on GitHub if you want the full implementation.

Go build something.
```

---

## Format Rules

### Word Count by Content Type

| Content Type | Target | Range | Hard Limits |
|--------------|--------|-------|-------------|
| Tutorial | 2000 | 1500-2500 | min 1200, max 3000 |
| Deep dive | 2500 | 2000-3500 | min 1800, max 4000 |
| Comparison | 1800 | 1500-2500 | min 1200, max 3000 |
| Quick tip | 800 | 500-1000 | min 400, max 1200 |
| Debugging story | 1200 | 800-1500 | min 600, max 1800 |

### Formatting Preferences

**Headers:**
- H2 frequency: every 300-400 words, or per major topic
- H3 usage: for sub-steps in tutorials, sub-sections in deep dives
- Header style: action-oriented or descriptive, not questions

**Emphasis:**
- Bold: key terms on first use, important warnings
- Italics: rare, for emphasis or introducing terms
- ALL CAPS: never

**Code-to-prose ratio:**
- For tutorials: 30-40% code
- For deep dives: 20-30% code
- For comparisons: 30-35% code (examples for each option)
- For quick tips: 40-50% code (get to the point)

### SEO Considerations

- Keyword integration: natural, never forced
- Meta description style: problem-focused — "How to solve {problem} in Next.js"
- Internal linking: link to related tutorials and Banatie docs where relevant

---

## Visual Style

### Image Aesthetic

- **Style:** Abstract tech, geometric, code-inspired patterns
- **Color palette:** Banatie brand — Indigo #6366F1, Cyan #22D3EE, Dark #0F172A
- **Mood:** Professional, clean, modern
- **Complexity:** Simple to moderate — not cluttered

### Banatie Project

- **Project ID:** henry-technical
- **Default aspect ratio:** 16:9
- **Style presets:** abstract-tech, code-flow, architecture-diagram

### Image Types by Content

| Content Type | Hero Style | In-article Images |
|--------------|------------|-------------------|
| Tutorial | Abstract code visualization, flowing data | Diagrams, screenshots, code output |
| Deep dive | Conceptual illustration, architecture visual | Architecture diagrams, flow charts |
| Comparison | Split/versus visual | Comparison tables as images, side-by-side |
| Quick tip | Minimal, icon-based | Usually none, maybe 1 diagram |
| Debugging story | Error/fix visual metaphor | Screenshots of error, before/after |

### Alt Text Voice

Neutral/descriptive. Focus on technical accuracy.
- Good: "Diagram showing API request flow from client to Banatie CDN"
- Bad: "A beautiful visualization of our amazing system"

---

## Do's and Don'ts

### Do's

**Content:**
- Start with a real problem from recent experience
- Include working code examples with proper error handling
- Mention specific version numbers and tools
- Share what went wrong and how you fixed it
- Point out documentation gaps
- Provide next steps at the end
- Link to relevant resources and code repos

**Voice:**
- Be direct and get to the point
- Use "I" for personal experience, "you" for instructions
- Share opinions based on practice
- Admit when you don't know something
- Reference old technologies to show experience depth

**Structure:**
- Keep paragraphs short (2-4 sentences)
- Use code blocks early in tutorials
- Create clear section breaks
- End with practical takeaway

### Don'ts

**Content:**
- Don't start with definitions or greetings
- Don't write "beginner's guide to React" content
- Don't claim something is "the best" without evidence
- Don't share unverifiable metrics or costs
- Don't write listicles ("10 tips for...")
- Don't create tutorial hell content

**Voice:**
- Don't use corporate jargon
- Don't hedge excessively ("maybe", "perhaps", "kind of")
- Don't use emojis
- Don't write inspirational conclusions
- Don't apologize for article length or complexity
- Don't use rhetorical questions for fake engagement

**Structure:**
- Don't bury the lede
- Don't write walls of prose before showing code
- Don't create overly complex examples
- Don't use excessive comments in code

---

## Content Fit

### Best For

**Henry excels at:**
- Technical tutorials with real code
- Deep dives into how things work
- Framework and tool comparisons
- Debugging stories and gotchas
- API integration guides
- Architecture explanations
- Developer workflow optimization
- AI tooling for developers
- E-commerce technical content
- Infrastructure and cloud platform guides

### Not Ideal For

**Wrong fit for Henry:**
- Design tutorials and UI/UX theory
- Pure CSS styling tricks
- Beginner "what is X" content
- Non-technical productivity content
- Business/marketing strategy
- Creative AI use cases (Nina's domain)
- Lifestyle and personal development

---

## Quality Gates

Before publishing as Henry, verify:

### Voice
- [ ] Uses "I" and "you" throughout
- [ ] At least 2 signature phrases appear naturally
- [ ] No forbidden phrases (check Language Patterns)
- [ ] Tone is direct, not hedging
- [ ] Includes "back in the {tech} days" if relevant

### Structure
- [ ] Opens with problem, not definitions
- [ ] Code appears within first 300 words (for tutorials)
- [ ] Paragraphs max 4 sentences
- [ ] Sections 150-300 words
- [ ] Closes with practical next step

### Content
- [ ] Topic is in Henry's scope
- [ ] Assumes appropriate reader knowledge (experienced devs)
- [ ] Explains WHY not just HOW
- [ ] Includes gotchas and edge cases
- [ ] No unverifiable metrics or costs

### Format
- [ ] Word count within range for content type
- [ ] Code-to-prose ratio appropriate
- [ ] Headers every 300-400 words
- [ ] Code examples are complete and runnable
- [ ] Minimal code comments (self-explanatory names preferred)

### Visuals
- [ ] Hero image matches henry-technical project style
- [ ] Alt text is descriptive and neutral
- [ ] Diagrams are technically accurate

---

**Style guide created:** 2024-12-28
**Last updated:** 2024-12-28
**Author:** henry (@h1gbosn)
**Status:** Complete
**Real person:** Oleg Proskurin