I added What’s Happening to datespots.city. On a city homepage, a button opens a sheet showing things going on soon: Ticketmaster events alongside my own street fairs and parades, grouped into today, tomorrow, and upcoming.
That was the feature. Everything after that was about making it feel like it belonged, then making sure it didn’t make the site slow.
First I made it feel native
Early on it worked, but it looked bolted on.
So I spent time on the boring stuff that users actually notice. The button sits under the city intro alongside Map and Plan, the sheet works properly on phones, and the labels use the local language for each city. If nothing is happening, there is a calm empty state instead of something that looks broken. Closing the sheet shouldn’t yank the page around, and cards shouldn’t flash while you scroll.
None of this is particularly clever. It just stops the feature from feeling like a demo.
Then I fixed who does the heavy lifting
The sheet needs fresh event rows, and pulling those from the database on every city homepage load was too expensive. You could feel it on a cold hit.
So I split the work. A small events service still talks to Ticketmaster and writes events into my database. After each sync, it also prepares a ready-made copy of what’s happening for each city and puts it into a fast edge cache, keyed by city and local calendar day.
The website only needs to read that copy. If the cache misses, it can still fall back to the database, but with a short time budget so a bad day for the events service never makes the city page slow.
I also prepare today, tomorrow, and the day after ahead of time. Midnight in Barcelona shouldn’t mean waiting for someone to visit before I rebuild the list for the new day.
The freshness is intentionally straightforward. What’s Happening is as fresh as the last successful sync, which currently happens a couple of times a day. It isn’t live-to-the-second Ticketmaster data, and for answering “what’s worth doing this week?”, it doesn’t need to be.
I used the same idea on the city picker
On the main datespots.city homepage, cities used to appear in a fixed demand order. Someone visiting from Austin could scroll past a wall of New York, London, Paris, and other cities before getting to Austin.
Cloudflare already attaches a rough location to each request, so I now use that to quietly move nearby cities toward the top. It is still the same search grid with the same links. There is no “near you” label, and I don’t automatically redirect anyone to a city subdomain based on their IP.
If the location is missing or looks wrong, I use the old order. The page never depends on geo to load.
Caching still works normally. I keep track of which nearest-city version of the homepage I cached, so visitors in different edge locations don’t end up receiving someone else’s ordering. The additional work per request is tiny.
What I didn’t do
I didn’t turn What’s Happening into its own SEO section. Live Ticketmaster links stay inside the sheet rather than becoming temporary pages across the site.
I didn’t automatically send someone to austin.datespots.city because their IP suggested Austin. Guessing wrong is worse than letting someone choose.
I also didn’t pretend the event feed is realtime when it isn’t.
The through-line
The pattern behind all of this is fairly simple: ship something people can use, make it feel like it belongs, move expensive work away from the request path, and keep the parts users actually touch as thin as possible.
The same thinking applies to smaller improvements. Location can make the city picker better without becoming a dependency. Event data can make city pages more useful without making them slower. A new feature doesn’t need to become a new SEO surface just because the data exists.
That’s the stretch from “I have What’s Happening” to where I am now.