01 · A working context-engineering case study

PREHOG

Context before credentials.

I am now exploring other opportunities with teams that value clear context, autonomy, and thoughtful delivery. Context First develops these principles beyond this original case study.

This project began while I was exploring a Context Engineer opportunity with PostHog. Today it is a maintained case study in context engineering and my first production implementation of PostHog.

02 · The principles behind the project

What drew my interest

I value teams that write decisions down, ship useful work, and learn from real usage. PostHog's public writing offered a useful example of those principles when I began this project.

  • Autonomy with clear accountability
  • Documented decisions and shared context
  • Small teams that treat writing as part of engineering
  • Useful work informed by real-world feedback

03 · Why Context Engineering

The throughline in my work

Software engineering, reliability, interaction design, technical communication, and AI workflow engineering all depend on clear context. It is the thread that connects my work across those disciplines.

Make the next step clear for the person or system doing the work.

See the evidence on /about

04 · How I work

How I work

I start by understanding the problem, then structure the work, build it, test it, observe the result, and document what changed. This presentation followed that same process.

05 · Evidence

Relevant work

Three projects that show how I approach context, systems, and documentation.

localcrew

Local inference orchestration

A local-first harness that connects Ollama and OpenAI endpoints across a LAN into one usable inference network.

View source

promptpad

Local-first prompt refinement

A tool that turns brief instructions into polished, copy-ready prompts, running entirely on local LLM inference via Ollama.

View source

prehog

Instrumented application project

A small PostHog implementation with Playwright coverage, a reviewer-facing README, and structured context for coding agents.

View source

06 · Learning PostHog through implementation

What I am measuring

This is my first production PostHog install. I started with a short list of questions, then added only the events needed to answer them.

Question Signal
Do people meaningfully progress through the deck?prehog_slide_viewed
Where do sessions stop?prehog_slide_viewed vs. prehog_completed
Is the navigation discoverable on mobile?prehog_navigation_used + masked replay
Do reviewers inspect the repository?prehog_outbound_clicked
Does anyone let it auto-play, or take control?prehog_autoplay_toggled

That question-first approach spread beyond this one page. Building it properly here showed what a real analytics architecture actually needs: a shared consent layer, generalized into a small library now used across the site's primary public surfaces. It carries the same discipline everywhere: specific, meaningful interactions, with visitor control designed in from the start.

See what it covers

07 · Context for humans and agents

Documentation for people and agents

The project keeps its architecture notes, decisions, and analytics rules in the repository. The README.md gives a reviewer the story; AGENTS.md gives a coding agent the working context.

Read AGENTS.md

08 · Principles for my next team

Context, trust, and remote work

My experience spans full-stack products, QA automation, documentation, and AI-assisted workflows. The following notes capture what resonated with me in PostHog's public handbook during my original research. They also inform the qualities I am looking for in my next team.

  • PostHog's culture handbook: fully remote across 20+ countries, Tuesdays and Thursdays kept free of internal meetings, and a default to "not asking for permission" if you're acting in the company's interest, a bias toward shipping.
  • PostHog's communication handbook: async-first, with internal email avoided "in nearly all cases," with exceptions carved out for legal approvals, official company documents, and communication with external partners.
  • PostHog's small-teams handbook: each team runs "as close to its own startup as possible," with the final call on what ships and no need for external QA or control.
  • No Rules Rules (Hastings & Meyer) argues: give people context, not control, and trust them to act on it.
  • PostHog names that book directly, twice: its company story lists No Rules Rules under "Things that influenced us," and its spending-money handbook names it as the direct influence behind its context-based expense policy.

My takeaway is broader than one company or role: useful written context helps teams make responsible decisions with less coordination overhead. I am actively considering opportunities built around these principles. Explore working together, or read Context First for the generalized approach.

09 · Inspect the work

Take a look

GitHub github.com/benmcnulty/prehog Resume benlive.tv/about Portfolio benlive.tv/portfolio Home benlive.tv

A short feedback survey may appear here after you finish the presentation.