- The Idea
- The First Prototype: Just a Spotify Connection
- Putting It on a Map
- Dropping the “You Need Spotify” Requirement
- Designing Against Abuse
- A Side Quest: Considering (and Rejecting) Bots to Make It Feel Busier
- Adding Japanese/English Language Support
- What Deploying Actually Taught Me
- Where Things Stand
- What’s Next
The Idea
What if you could see, on a map, where people are right now and what they’re listening to? That simple “what if” is where this project started.
The concept: link whatever’s playing on Spotify to your current location, and share it. I named it TrackTrip — a track, and the trip you take following where those tracks lead.
This is a record of how the prototype came together: what got built, where I got stuck, and what I was thinking along the way.
The First Prototype: Just a Spotify Connection
The first version was genuinely tiny.
・Registered an app on the Spotify Developer Dashboard
・Went through OAuth 2.0 to get authorization, then pulled the currently-playing track via the API
・Spun up a minimal Node.js + Express server
The moment “the currently playing track shows up on screen” actually worked, it was a small thing, but it felt good. Everything else got layered on top from there.
Putting It on a Map
Once the track data was flowing, it was time for the part that’s actually the heart of the app. I pulled the user’s location with the browser’s Geolocation API, rendered a map with Leaflet.js + OpenStreetMap, and built the mechanism for dropping a pin — track plus location — wherever someone shares.
One small decision made early on ended up mattering a lot later:
Pins are shaped like map markers, but filled with the sharer’s icon or the track’s album art, cut into that pin shape.
I didn’t want plain round markers. I wanted a glance at the map to tell you who shared what. Hovering (or tapping, on mobile) brings up the track details and a quick glimpse of that person’s profile.
Dropping the “You Need Spotify” Requirement
Somewhere in the build, it became obvious: if the app requires a Spotify login to do anything at all, fewer people will bother trying it.
So I changed course.
・No login required. Anyone who visits can share a track immediately
・Track and artist names can be typed in by hand — Spotify becomes a “nice to have” convenience layer, not a requirement
・Who posted what is tracked with an anonymous ID stored in the browser
That decision paid off later, too — when I added playlist sharing, it worked without a login from day one, for the same reason. “Lower the barrier to participate” became something I started checking every time I added a feature.
Designing Against Abuse
Once you’re building something more than one person will use, you can’t avoid thinking about bad actors. Two things gave me the most trouble here.
1. One active share per person
To keep the map from turning into clutter, each person can only have one active share at a time. Sharing something new automatically retires the previous one.
2. People clearing their browser data to post over and over
Since the anonymous ID lives in the browser, wiping it in theory lets anyone reappear as a “new person” and post endlessly. My first fix was a blunt one: cap each IP address to one active share, period. That backfired — people on the same household Wi-Fi, the same office network, or even the same mobile carrier’s shared IP pool started accidentally wiping out each other’s posts.
I ended up replacing it with rate limiting instead: if a lot of new posters suddenly show up from the same IP in a short window, that gets throttled — without touching anyone else’s existing posts. It’s the kind of balance you only really discover once real people are using the thing.
3. Never actually delete the data
A share stops being visible under exactly three conditions: 48 hours pass, the person deletes it themselves, or they post something new. But under the hood, nothing is hard-deleted — it’s just flagged as inactive. The idea is to keep the history around for features like follows, further down the road.
A Side Quest: Considering (and Rejecting) Bots to Make It Feel Busier
I’ll be honest about this one. With so few real users, the map looked sparse, and at one point I seriously considered a feature where ~100 bots would post tracks from random locations across Japan on a rolling basis.
Before writing a line of code, I stopped and thought it through. What that would actually do is trick real visitors into believing a lot of people are using the app when they aren’t. It’s structurally the same problem as fake reviews or fake followers.
I scrapped the idea. If I ever do seed the map with placeholder content to make it feel more alive, it’ll be clearly labeled as a sample — transparency, not illusion. It’s a small thing, but deciding what not to build felt worth writing down too.
Adding Japanese/English Language Support
Around the same time I renamed the site to “TrackTrip,” I added a language toggle between Japanese and English. It detects the browser’s language on first visit, and there’s a switch in the top corner to change it anytime. Even the dynamically generated bits — map pin tooltips, error messages — get translated, not just the static page text.
What Deploying Actually Taught Me
Getting it running locally is one thing; putting it in front of people is another. Looking for something free that wouldn’t lose data, I landed on this pairing:
・Render for hosting the app itself (free tier, auto-deploys from GitHub)
・Supabase for the database and image storage (free tier, PostgreSQL)
Migrating off the file-based mini database (lowdb) I’d started with, over to Supabase, was more tedious than expected. Things that worked flawlessly locally kept tripping over deployment-specific quirks — files disappearing on every redeploy, a mistyped environment variable — which is a very familiar flavor of pain if you’ve shipped anything before.
Even after launch, a few things only showed up once it was live:
・A pasted-in URL typo meant the app couldn’t reach Supabase at all
・Spotify’s authorization codes expiring before the exchange completed
Nothing dramatic — just the usual process of finding and fixing things one at a time.
Where Things Stand
・A location-linked music-sharing map
・Track and playlist sharing with no login required (manual entry or Spotify, either works)
・Profile settings — nickname, uploaded avatar, pin color, bio
・One-share-per-person limit, plus abuse mitigation
・Manual deletion, automatic 48-hour hiding (data itself is retained)
・Only official Spotify / Apple Music / YouTube / YouTube Music links are clickable
・Japanese/English toggle
・Live, in production, on a free-tier stack
What’s Next
・A follow feature (the decision not to delete data was made with this in mind)
・Monetization — holding off for now until there’s a clearer signal from real usage
・Deeper investment in playlist sharing
Build small, use it, fix it. That’s been the loop so far. For now, the plan is to keep iterating based on how people actually use it.


コメント