C
Carol Bolger
Guest
What a near-identical app taught me about building in public.
Four days after I opened public testing for my nutrition app, I checked the Play Store for something unrelated and found another app with the exact same name. Same core idea, too: you tell it what you’re about to eat, it tells you the one thing to add so the meal actually holds you.
At first I assumed it was a coincidence — the name wasn’t especially unique, and “one thing” apps are a crowded little genre. Then I read the actual listing. It wasn’t just the name. It knew where you were eating and adjusted its suggestion for an airport versus your own kitchen. It remembered what you kept in your pantry and started suggestions from there. It never re-suggested something you’d said no to. It had a paid tier built around saving combinations that worked for you. Every one of those is a specific, non-obvious product decision — not something two developers land on independently by chance.
My first instinct was to feel wronged. My second, more useful instinct was to figure out what I could actually do about it — and that’s the part worth sharing, because the honest answer surprised me.
The legal reality is thinner than it feels
Copyright protects the specific words and code you wrote, not the idea behind them. A feature set — even a distinctive one — generally isn’t something you can claim ownership of. My app’s description was paraphrased on their listing, not copied verbatim, which meant even a copyright claim on the text itself was weak.
Trademark felt like the stronger angle until I looked closer. Trademark rights typically come from public use in commerce — and my app had only just moved from private testing to a public listing the same week theirs appeared. I couldn’t even confidently say I’d been “first” in the way that matters legally, regardless of how much earlier I’d actually built it.
That was the uncomfortable lesson: months of private work don’t count for much against someone else’s few days of public listing. If naming rights ever come down to a dispute, the clock that matters is public, not the one on your own machine.
Three things I’d do differently
Think about what “building in public” actually exposes.
Public build logs, spec documents, and early testing tracks are genuinely useful — for accountability, for feedback, for momentum. But they’re also a fairly complete blueprint of your product decisions, available to anyone looking, well before you have any real head start. I’m not saying stop building in public. I’m saying know what you’re trading for that visibility.
Reserve your name everywhere, before you need it.
I’d been told this and even acted on it for one platform — but not consistently across every store, and not as early as I could have. A name reservation costs almost nothing and forecloses exactly this kind of collision. Do it in week one, not whenever you get around to it.
If it happens anyway, don’t reach for a fight — reach for a fix.
My instinct was to feel entitled to something: a takedown, an apology, at least an acknowledgment. What actually helped was asking a narrower question: what’s the fastest way to remove the confusion for the people who matter — my users, not the other developer? For me that meant renaming. It felt like a concession at first. In practice it took an afternoon, cost nothing, and the name I landed on ended up more distinctive and more true to what the app actually does than the generic one I’d started with.
The part that’s easy to miss in the moment
None of this required certainty about what happened on the other side — and I don’t have that certainty, and I’m not claiming to. I don’t know whether it was a coincidence, a parallel build, or something closer to a copy. What I know is that chasing an answer to that question wouldn’t have shipped my app any faster, and it wouldn’t have made my users’ experience any better. The fix that actually mattered was the one entirely in my own control.