Chrome extensions are just web pages with superpowers — but the superpowers come with rules. This is the beginner's map: the parts, the permissions, why your popup can't see the page you're looking at, and the caveats that bite everyone exactly once.

You built the extension and it works with "Load unpacked". This is the map of everything between that and a public Chrome Web Store listing: the one-time $5 fee, the images the listing needs, the privacy paperwork, the review, and the maintenance that never quite ends.

Part 1 let the server reach the browser; Part 2 gave the browser an equal voice back. But in both, every byte still travels through a server. This final part is about the one browser technology that removes the server from the middle: WebRTC, which lets one browser talk straight to another — video, audio, and data, peer to peer.

In Part 1 the server learned to talk without being asked — but the browser could still only listen. A chat, a multiplayer game, a collaborative editor: these need both sides speaking freely over one connection. This is Part 2 of the series, and it's about the browser's true two-way channels — WebSockets, the workhorse, and WebTransport, its modern successor.

Plain HyperText Transfer Protocol (HTTP) has one stubborn rule: the browser asks, the server answers, and then the line goes dead. So how does a chat notification, a live score, or a stream of tokens from a language model reach a page that never asked again? This is Part 1 of a three-part tour of the browser's networking beyond request–response — and it starts with the three ways a server can reach you.

Every post on this blog needs two images that do completely different jobs: a social card that has to earn a click in a feed, and an inline hero that opens the article. This post is about how the blog makes both — a typographic default that costs nothing, an opt-in artificial-intelligence (AI) cover that costs about four cents, and the little Model Context Protocol (MCP) server that wires an image model straight into Claude Code. The cover above was made by that exact pipeline.

You've seen this screen a thousand times: a dark page, the domain name in bold, "Performing security verification", and a lonely checkbox with the Cloudflare logo. It feels like a speed bump, but there's a surprisingly rich pipeline behind it — and, importantly, none of it runs on the website's own servers.

Software teams generate an ocean of numbers — commits, tickets, story points, lines of code — yet the thing we actually care about, performance, stubbornly resists measurement. This post is about that gap: why individual output is so easy to misjudge, what signals are worth watching, and how to measure teams without corrupting the very behavior you want.

"Self-maintaining" is a seductive phrase, so let's be honest about it up front. You're not going to walk away for a month and come back to a repo that grew new features on its own. What you can build is a loop where Claude does most of the mechanical work — turning issues into pull requests (PRs) — and a separate Claude pass reviews that work before it ever reaches you. You stay the final gate, but you review a clean, already-critiqued PR instead of a blank diff.

You add a <script> tag, the page runs your code. Underneath that one line the browser does a surprising amount of work: it decides when to run the script, fetches every file it depends on, figures out what each file is asking for, keeps every loaded module in memory so it runs exactly once, and evaluates them all in the right order. This is a tour of that machinery.