Building Spatial Memory Part 4: The Brutal Reality of Launching a Location-Based Side Project (After 3 Months)

Honestly, I didn't expect to be writing this fourth article. When I started building Spatial Memory—the "Pinterest for the Physical World" where you pin memories to GPS coordinates that only unlock when you're physically there—I thought "Okay, cool idea, build it, launch it, maybe a few hundred people will try it."

Three months later... let's just say I learned the hard way that location-based apps have a chicken-and-egg problem the size of Mount Everest.

If you've been following along, this is what we've covered so far:

Today, I want to talk about what happens after you build it and no one comes. Because that's the reality for 99% of side projects, especially location-based ones. Let's get honest.

So here's the thing: Cold Start is Way Harder Than You Think

I built the whole thing. Backend in Go, AR frontend in Kotlin with ARCore, spatial indexing with PostGIS, caching with Redis GEO, photo storage on Cloudflare R2 (zero egress fees, still love that part). Everything worked. I tested it on my local hikes, pinned a few memories around my city, it was cool.

Then I launched. I posted on Hacker News, Reddit, a couple Discord servers. What do you think happened?

Total signups: 17 people.

Total pins created: 23 pins.

Most pins are in my city because I created them.

Yep. That's it.

I knew going in that location-based networks have a cold start problem. You need users to have pins, you need pins to attract users. It's obvious. But knowing it intellectually is completely different from living it.

When you check your admin dashboard every morning and see zero new users for three weeks straight... that's when the self-doubt creeps in. Did I waste three months of weekends on something nobody wants?

Why It Didn't Take Off (The Real Reasons)

I've spent the last month thinking about this, and I've identified five big mistakes I made. Maybe this will save you some time if you're building a location-based app too.

1. The Value Proposition Doesn't Work Until You Have Critical Mass

Let's be real: Why would you download an app where you can only discover memories if someone already put them where you're going? If you live in a city of 5 million people and there are 12 pins total, what's the point?

I thought "Okay, it's a network effect thing, but even early adopters can start putting pins." The problem is—early adopters don't want to put in all the work for no reward. They want to get value today, not "someday when other people join."

My original value prop was: "Discover cool hidden memories wherever you go." But when there's no memories, the value prop is empty.

2. GPS Accuracy is Still a Problem in 2026

I talked about this briefly in part 1, but it's worse than I thought. In open hiking areas, GPS is accurate to like 3-5 meters. That's fine. But in cities with tall buildings ("urban canyons"), it can be off by 20-30 meters.

Think about that. You pin a cool coffee shop on the corner, but the GPS drifts, so when someone actually goes to the coffee shop, the app says "You're not close enough—walk 25 meters that way." Which is the middle of the street. That's a terrible user experience.

I implemented a "force unlock" button so people can still see it even if they're not exactly at the coordinates. But that defeats the whole "only unlock when you're physically there" magic. So what's the point of the location constraint then?

Here's what I learned the hard way: GPS accuracy isn't a solved problem, even with modern phones. Don't build your entire product around the assumption that it is.

3. The "Cool Idea" Isn't Enough for People to Actually Use It

People love the idea when I tell them. "Oh that's so cool! Pinning memories to places? Yeah that sounds awesome." Then when you ask them to actually download the app, open it, create an account, and go pin something... suddenly they "don't have time right now."

Ideas are cheap. Getting people to actually change their behavior is hard. Most people don't walk around going "I wish I could pin a memory to this exact spot." They take a photo and post it to Instagram. Done.

The novelty of location-locked content wears off after your first pin. Then what? I don't have a good answer for "what's next" yet.

4. AR is Cool But Batteries Hate It

I really wanted the AR experience where you point your phone at the landscape and see pins floating where people pinned memories. It looks amazing in demos.

But here's the reality: ARCore keeps your screen on, keeps the GPS active, keeps the camera active. After 30 minutes of walking around, your battery is at 30%. That's a non-starter for most people. They're not going to carry a power bank just to use your little side project app.

I implemented battery optimizations—turning off AR when you're just browsing, background location throttling, all that good stuff. But the reality is: any app that uses AR and GPS continuously is going to drain your battery. That's just the current state of mobile hardware.

5. I Underestimated Privacy Concerns

People see "this app tracks your location all the time" and they get nervous. Rightfully so. I built progressive permissions—you only share location when you're actively using the app, I don't track you in the background, all the actual pin data is public anyway. But explaining that to users is hard. The default reaction is "Why does this app need my location?"

I think privacy is actually a feature of this design—all pins are only discoverable when you're physically there, but your browsing history never leaves your device. But that's a subtle benefit that's hard to communicate in a 30-second app store description.

What Actually Works (The Surprising Wins)

It's not all bad, though. Some things actually worked way better than I expected. Let's talk about the good stuff too.

The Tech Stack is Solid

I went with Go + PostgreSQL + PostGIS + Redis + Cloudflare R2. That stack has been rock solid.

Here's my approximate daily usage:

Daily active users: ~3 (me + two friends)
Daily requests: ~150
Database size: ~1.2 MB
Monthly hosting cost on Fly.io: $2.18

That's it. It costs me barely more than a cup of coffee per month. The response times are consistently under 50ms. Even if I had 100x more users, it would still scale fine on the same tier.

Cloudflare R2 was definitely the right call. Zero egress fees, pre-signed URLs for direct uploads from client, my backend never touches the image bytes. I've never had a single issue with it. That's one of the best decisions I made.

Example of how clean that R2 direct upload flow is in Go:

// Generate pre-signed URL for direct client upload
func (s *StorageService) GetPreSignedUploadURL(ctx context.Context, filename string, contentType string) (string, string, error) {
    // Put the key with user prefix to keep organized
    key := fmt.Sprintf("uploads/%s/%s", currentUserID, filename)

    // 15 minutes expiration is enough for upload
    req := s3.PutObjectInput{
        Bucket: aws.String(bucketName),
        Key:    aws.String(key),
        ContentType: aws.String(contentType),
    }

    presignedReq, err := s.presigner.PresignPutObject(ctx, &req, 15*time.Minute)
    if err != nil {
        return "", "", err
    }

    // Return the pre-signed URL for upload, and the public URL after upload
    publicURL := fmt.Sprintf("https://%s.r2.cloudflarestorage.com/%s/%s", accountId, bucketName, key)
    return presignedReq.URL, publicURL, nil
}

The client just PUTs directly to R2. My backend never sees the image. Super clean, super cheap, infinitely scalable. I'd do this again 10/10.

Spatial Search Performance is Still Great

Remember in part 2 when I got from 8 seconds to 20ms with PostGIS + Redis GEO? That's still holding up. Even with the (admittedly small) dataset, every spatial query returns in under 25ms.

Here's the core query that does all the heavy lifting:

-- Find all points within X meters of a coordinate
SELECT 
    p.id,
    p.latitude,
    p.longitude,
    p.title,
    ST_Distance(
        ST_Transform(p.geom, 3857),
        ST_Transform(ST_SetSRID(ST_MakePoint($1, $2), 4326), 3857)
    ) as distance
FROM pins p
WHERE ST_DWithin(
    ST_Transform(p.geom, 3857),
    ST_Transform(ST_SetSRID(ST_MakePoint($1, $2), 4326), 3857),
    $3 -- distance in meters
)
ORDER BY distance
LIMIT 20;

And we cache the candidate IDs in Redis GEO so we don't even hit PostGIS for popular areas:

// Add to Redis GEO cache
err := r.geoAdd(ctx, "pins:geo", &redis.GeoLocation{
    Name:      strconv.FormatInt(pinID, 10),
    Longitude: lon,
    Latitude:  lat,
}).Err()

This architecture works. Even when we get more pins, it's going to keep working. That part I got right.

Privacy by Design Feels Good

I built this with privacy from the ground up:

You only share location when you're actively using the app
All browsing happens locally—your search history never leaves your device
Pins can be private, friends-only, or public—you choose
No tracking, no analytics, no selling your data

That feels right. Even if it doesn't help with user growth, it's the right way to build an app like this. I sleep better at night knowing I'm not harvesting user data.

Honest Pros & Cons After Three Months

Let me break this down like I always do—no marketing fluff, just the real deal.

✅ Pros

Super cheap to run - $2/month for everything, can handle thousands of users before needing to scale up
Tech architecture is solid - The PostGIS+Redis+R2 stack works perfectly, no weird hacks
Privacy is actually done right - Users are in control, no tracking, data stays where it should
The core experience does work when you have pins - When you're hiking and find a pin someone left at a viewpoint, it is magical
I learned a ton about Go, ARCore, spatial databases - Three months of good learning, that's already worth it for a side project

❌ Cons

Cold start problem is real and hard - No users = no pins = no users. It's a vicious cycle
GPS accuracy is still a limiting factor - Urban canyons kill it, users get frustrated
AR kills battery - Cool factor isn't worth the battery drain for most people
Value proposition requires critical mass - Doesn't work well for the early users who carry the burden
Competes with Instagram which already does photos - Why would anyone use this instead?

Who Should Actually Build a Location-Based App Today?

After going through this, here's my hot take: Build it if you're building it for a specific niche, not a general audience.

General consumer location-based social networks already have all the network effects with Google Maps and Instagram. You're not going to beat them. But if you can target a specific niche where location-locked content actually solves a real problem, that's where you have a chance.

For example:

Urban exploration communities - They already explore hidden places, why not pin notes?
Hiking/trail groups - Pin water sources, trail conditions, great viewpoints
Local food scenes - Pin secret menu items at hole-in-the-wall restaurants
Street art tours - Pin murals and street art locations with artist info

These niches already have active communities. They just need a tool that does the location-specific thing better than what they're using now (probably a shared Google Doc). That's where you can get that initial critical mass.

I built a general "Pinterest for physical world" and that was probably my biggest strategic mistake. Too broad, needs too much mass to work.

Would I Do It Again?

Honestly... yeah, I would.

Side projects aren't always about making the next unicorn. Sometimes they're about exploring an idea you think is cool, learning new technologies, and seeing what happens. I spent three months working on this in my evenings and weekends. I learned more about spatial databases, Go backend development, mobile AR development, and product launch than I would have if I just watched YouTube tutorials.

Is it the successful hit I hoped for? No. Will it ever be? Probably not. But that's okay. Some side projects are just experiments. And this experiment taught me more than I expected.

The funny thing is—because I'm writing this series of articles about building it from scratch, more people have read these articles than have actually used the app. Which is weird, but also okay. If my mistakes can help someone else avoid them, that's value right there.

So What's Next for Spatial Memory?

The code is still on GitHub if you want to poke around or run your own instance. It works fine, it just doesn't have users. I'm not going to shut it down—it's only $2/month, so it can stay up as long as Cloudflare and Fly.io keep the lights on. If you happen to be in Shanghai and want to check out the pins I've left around the city, download it and go for a walk. It's actually pretty fun.

I might add features here and there when I get inspired. I've got a couple ideas for improving the GPS accuracy with sensor fusion, and maybe adding offline maps for hiking areas with no cell service. But I'm not going to pretend it's going to be the next big thing.

Your Turn

Have you ever built a location-based side project? Did you run into the same cold start problem? Do you think location-locked content actually has a future, or is it just a cool idea that never quite works out?

Drop a comment below—I'd love to hear your thoughts and experiences.

Spatial Memory is open source and available on GitHub if you want to check out the code or contribute. Star it if you think the idea is cool, even if you don't use it!