You asked for Longmont and all the smaller nearby cities as sections of tasteboulder.com. Here's what the measurement says, what it costs, and the one question I need answered before anything gets built.

Short version: Longmont is the best expansion target we have, better than Boulder was when we started. Louisville and Superior are nearly free, because their restaurants are already in our database and only a single filter is keeping them off the site. And "all smaller nearby cities" turns out to have a fuzzy edge that's worth drawing deliberately, because three of the candidates are bigger than Boulder and would quietly change what this site is.

What I measured, and why all three parts matter

Three things, because any one of them on its own gives the wrong answer.

Demand. Monthly US search volume and keyword difficulty for "restaurants X" and "best restaurants X" in each town.

Competition. Who actually holds page one for the "best" phrase, how many of them are soft (Yelp, TripAdvisor, Reddit, tourism boards, the sites we don't have to beat), and how strong the weakest genuine competitor is. That last number is the real bar. It's what you actually have to clear, not the strongest site on the page.

Inventory. How many venues we already hold per town. This is the one that's easy to forget, and it reorders everything.

The table

Volume is the two phrases combined. "Held" is venues already in our database. "25+ reviews" is the subset with enough review volume to make a page worth publishing.

Who actually holds page one

This is the part that decides whether a town is winnable, and it's why Longmont jumps the queue.

"Weakest real" is referring domains, which is the honest measure of how much authority a site has earned. Read the Boulder row first: when we started, the weakest genuine competitor on page one had 130 referring domains and the median was 344. We went in anyway and it worked.

Longmont's weakest real competitor has 10. The median is 56. That's an order of magnitude softer than the fight we already won, at just over half the search volume, in a town twenty minutes up the Diagonal.

Longmont's page one is currently four soft results plus five small local sites, the strongest of which is a single restaurant's own website. There is no dedicated Longmont dining guide holding that page. That is the same shape of gap that made Boulder worth building, only wider.

Where the edge of "nearby" actually is

Here's the thing worth deciding on purpose rather than by accident. Some of the towns that scored well are not small neighbors of Boulder. Arvada, Westminster and Thornton are Denver suburbs, each of them bigger than Boulder, none of them in Boulder County, and none of them somewhere a Boulder reader thinks of as local. Adding them wouldn't be expanding TasteBoulder. It'd be turning it into a Front Range site with a Boulder name, which is a different product and a harder one to make coherent.

So I'd draw it in three rings:

Ring 1, Boulder County, unambiguously ours. Longmont, Louisville, Lafayette, Superior, Erie, Niwot, Nederland, Lyons. Combined volume 41,840 a month, which is more than Boulder's own 39,200. The name still fits, the geography still makes sense, and a Boulder reader genuinely drives to these places for dinner.

Ring 2, adjacent and defensible. Estes Park, Golden, Broomfield. Combined 60,000 a month, and Estes Park alone is nearly the size of Boulder. Estes Park is the interesting one: it's a tourist town, which means high-intent visitors searching from out of state, and a page one whose weakest real competitor has five referring domains. It's also 35 miles away in a different county, so it stretches the brand. Worth doing, worth doing second, and worth a moment's thought about whether it belongs here or in its own property.

Ring 3, the Denver suburbs. Arvada, Westminster, Thornton, Brighton. Combined 25,840. I'd leave these alone for now. Not because the numbers are bad, but because they change what the site is, and that decision deserves its own conversation rather than being smuggled in as "nearby".

Two towns are already built and switched off

This is the most useful thing in the whole analysis.

Louisville (53 venues, 45 with real review counts) and Superior (32 venues, 25 with real review counts) were swept up inside Boulder's discovery radius months ago. Their data is in the database right now, already paid for, already carrying reviews. Lafayette has 10 and Niwot has 1, which are too thin to publish as they stand.

The only thing keeping Louisville and Superior off the site is one line in export_site_data.py:

WHERE b.address_city = 'Boulder'

That's it. Nothing else. Publishing them is a code change and a build, not a data project. Louisville is 5,280 searches a month with a page-one weakest of 11 KD, and we already have the restaurants.

What it costs

The whole Boulder build, 694 published venues with 39,345 reviews, 1,957 menus and 33,026 priced dishes, has cost $8.05 in API spend to date. Broken down:

That's about 1.2 cents per published venue, all in. Longmont is a smaller city than Boulder, so the full pipeline there lands somewhere around $4 to $6. Ring 1 in its entirety is likely under $15.

Money is not the constraint here, and I want to be plain about that so it doesn't get treated as one. The constraints are your time reviewing what gets published, and the pipeline's own quality gates, which is where the Boulder build actually cost effort: closure checking, photo identity verification, and stopping a calorie count being published as a price.

The one decision I need before building anything

How do the URLs work?

Today every venue lives at tasteboulder.com/restaurants/<name>/, flat, with Boulder assumed. The moment a second town exists, that has to change, and changing it later means redirecting hundreds of pages that have started to rank. This is the expensive-to-reverse decision, so it's worth ten minutes now.

Option A, town folders. tasteboulder.com/longmont/restaurants/red-cedar-bistro/, with Boulder staying where it is at /restaurants/....

Clean, obvious to a reader, and each town gets a real hub page that can rank for "restaurants longmont" on its own. The cost is that Boulder and the other towns have different shapes, which is a small permanent wrinkle in the code.

Option B, town folders for everyone, including Boulder. /boulder/restaurants/... and /longmont/restaurants/....

Consistent and the tidiest long-term. The cost is real and immediate: every existing Boulder venue URL moves, which means several hundred 301 redirects on pages that are currently ranking. I can do that safely, we have a skill for exactly this, but it's a genuine risk taken for tidiness.

Option C, stay flat. /restaurants/red-cedar-bistro/ regardless of town, with the town as a filter.

Cheapest to build and the worst for search. It gives you no page that can own "restaurants longmont", which is the entire 21,000 searches a month we're going after.

I'd take Option A. It gets the ranking benefit, it costs no redirects, and the wrinkle it leaves in the code is smaller than the risk in Option B.

What I'd do, in order

1. Publish Louisville and Superior. One filter change, a build, a validation pass. 85 venues, 6,040 searches a month, essentially free because the data already exists.
2. Build Longmont properly. Full pipeline: discovery, reviews, menus, photos, identity checks. The single best target on the board.
3. Backfill Lafayette, Erie, Niwot, Nederland, Lyons. Lafayette and Niwot need real discovery runs, since what we hold is too thin to publish.
4. Then decide on Estes Park, on its own merits, as a separate conversation about whether it belongs here.

What I need from you

• The URL question above. That's the blocking one.
• Confirm Ring 1, and confirm you want Ring 3 left alone for now.
• Whether "TasteBoulder" is still the right name if the site covers the whole county. I think it is, since Boulder County is the container and Boulder is the anchor, but you should be the one to say so before we build 400 pages on the assumption.

Nothing here is built yet. This is the measurement and the recommendation, and the money involved is small enough that the real question is whether the direction is right, not whether it's affordable.