BBQ is a geography problem

The real geography of great barbecue is hyperlocal. It's not state-level or even county-level. It's a specific pit, in a specific town, run by a specific family, using wood from a specific local source, serving a specific regional customer base with specific expectations. The "Texas brisket" category obscures the fact that the brisket at Snow's in Lexington is nothing like the brisket at Franklin in Austin, which is nothing like the brisket at Louie Mueller in Taylor — and all three are within 100 miles of each other.

What makes this a geography problem rather than a cooking problem is that the variation is place-dependent in ways that aren't obvious from outside. The wood matters — post oak burns differently than hickory. The humidity matters. The local cattle supply matters. The customer base matters — a pit serving a rural lunch crowd has different incentives than one serving a weekend destination crowd. All of it is geographically determined, and none of it shows up in a category label.

There's a second layer under the geography: people don't hold these differences neutrally. A region's barbecue is a regional identity, defended for a century, and the defense is part of what keeps the style distinct — a pitmaster isn't converging on some national average, he's making the thing his town already expects. So the map isn't just uneven because of wood and cattle. It's uneven because everyone on it is deliberately holding their ground.

The discovery problem follows from this. If great barbecue is hyperlocal, then the tools we have for finding it are badly calibrated. Yelp and Google Maps optimize for volume and recency. They surface the places that get reviewed a lot, which are the places that are easy to get to, which are the places in cities, which are not where the best barbecue tends to be. The instrument measures foot traffic and calls it quality.

The best barbecue in Texas is often in a town of 3,000 people you'd have no reason to drive through unless you already knew it was there. The best barbecue in the Carolinas is often a cash-only lunch spot that closes when they run out, usually before noon. These places don't optimize for discoverability. They don't need to — they've fed the same community for 40 years. The thing that makes them great is the same thing that keeps them invisible to a national ranking: they were built for the people who already live there, not for the algorithm that decides what a stranger sees.

This is the problem BBQ Atlas is trying to solve. Not "here are the famous places" — that list already exists, and it's mostly the same twelve names copied between blog posts. But "here are the right places, distributed across the actual geography of where great barbecue happens to be made," looked at through a consistent method rather than one writer's afternoon.

The consistent method is where this stops being a food project and starts being a platform. The value has to be real first — a guide people trust, that sends them somewhere they'd never have found — and only then does it become the kind of asset where the marginal cost of the next city guide is close to nothing. That order is the opposite of how most barbecue content on the internet was built: most of it exists to rank, not to be right.

The map is the right interface for this. Not a list, not a ranking, not a category page. A map, because the insight is spatial. The insight is that there's a pit in Lexington, NC you've never heard of, and it's 20 miles off the interstate, and it's been there since 1977, and it's better than anything you've had at a place with a James Beard nomination.

You can only communicate that with a map. The distance, the context, the density are visible on a map in a way they aren't in a list, which throws away the one thing that decides whether you'll go: how far a place is from where you already are. Three great pits within an hour of each other off one stretch of highway is a trip; the same three in a list are just entries you'd never connect.

Here's the part that surprised me most about building it: BBQ Atlas isn't one website. It's five. There's a national hub at bbqatlas.co — the atlas itself — and four city guides that each go deep on one barbecue town: Austin, Kansas City, Memphis, and Charleston. All five render from a single Next.js codebase against one shared venue backend, so a tenant is a build target, not a fork — a data fix or a new feature lands across the whole network in one deploy, not five.

The backend was built as a reusable atlas platform on purpose, not as a barbecue one-off. It's a Django and Django REST Framework service on PostgreSQL, with models for venues, cities, styles, reviews, and rankings — the abstract shape of any place-based guide, pointed at barbecue first. Barbecue is just a good vertical to prove it on: the intent is inherently local and travel-adjacent. People research a city's barbecue before they visit it, which is exactly the shape the hub-and-spokes design serves.

The deploy is the part I trust most, built the way I build everything that touches production. Buildkite builds all five tenants behind a manual release gate, health-checks each one, then swaps the web server config — and rolls back automatically if any single tenant fails. A post-deploy smoke test hard-fails on liveness and data-freshness regressions, so a stale or dark site can't quietly ship. The safety isn't me watching closely; it's built into the deploy.

A map is the right interface for a human, but a crawler can't read a map. So the harder half of the work is turning the spatial insight into structure a search engine can see. Discovery sites live or die on how they render to crawlers, so the facet system is wired through the server, not bolted on in the browser. A view like burnt ends in Kansas City isn't a client-side filter that leaves the URL blank — it's its own server-rendered landing page, with a real title and a self-referencing canonical, and the interactive filtering layers on top.

So the geography ends up encoded as pages. Each venue carries Restaurant structured data, so the pit in a town of two thousand is described to a search engine in the same machine-readable shape as a famous name in a city — the small place gets looked at the same way as the big one, which was the point of building this instead of writing another list. The facet taxonomy spans the network's 156 tagged venues, and the filter behavior is verified with browser-level checks against production, because a facet page that renders empty to a crawler is worse than no page at all.

What I've learned from building it is that the discovery problem is harder than the cooking problem. The cooking knowledge exists. The pits exist. The challenge is connecting people who want great barbecue with the places that make it, across a geography that doesn't optimize for that connection — and doing it so a search engine, not just a friend who already knows, can surface it.

That's a software problem. It's also a geography problem. It turns out those are the same problem: the reason the best pit is hard to find is spatial, and the fix — a shared venue backend, a facet page per place, a map that keeps the distances — is a way of writing that geography down in a form the internet can read. The map was always the interface. The work was building the thing underneath that makes it true.