Wimemo
AI-native private travel photo memory app
I shortened our invite flow and expected activation to improve.
It didn’t.
The sender needed fewer taps, but the receiver still had to survive an App Store hop, a human approval step, and an in-app race before reaching value.
The number that forced me to admit this was our weekly funnel snapshot: 263 exposures -> 17 clicks -> 0 one-step link-ready events -> 0 one-step share-panel events -> 1 legacy link share -> 0 accepts.
Worse, the KPI I thought I was optimizing had a target (P50 <= 9 taps) but was structurally n/a because none of the required events were emitted yet.
So the real fix was not another cleaner screen.
I changed the system around the flow:
- preserved invite context across install
- bounded stale approval tokens on iOS
- changed the backend to store one join request per requester instead of consuming a shared link once
- added 31 join-loop tests plus server-side funnel events
The reusable lesson for me:
shortening the creator-facing step is not the same as reducing activation friction.
If activation depends on the receiver, define success from the receiver’s first value moment and instrument every boundary before claiming an optimization.
What looked cleaner in your growth loop but got worse once you mapped the install, approval, or first-value path end to end?
I’m building Wimemo, an iPhone app for organizing travel memories.
The original problem was simple: travel photos are easy to take, but hard to revisit.
After a trip, people often have hundreds or thousands of photos in their camera roll. The photos are saved, but the memory around them is scattered: places, notes, companions, plans, and what actually happened.
I don’t think this is only a photo organization problem. It feels more like a memory management problem.
That is the direction I’m exploring with Wimemo: turning trips, places, photos, notes, plans, and companions into a private memory system people can actually return to.
The other experiment is how the company is being built.
I’m trying to build Wimemo as an AI-native one-person company. AI helps with research, coding, SEO, QA, product thinking, release notes, support drafts, and marketing experiments. But the hard part is not “can AI do tasks?” It is keeping taste, context, and responsibility in one place.
The more I use AI, the more I feel the founder’s job becomes less about doing every task manually and more about designing the system around the work:
- what should exist
- what should not exist
- what shipped
- what failed
- what users actually care about
- what tradeoffs are worth making
I’m still early, but this feels like the most interesting part of building right now: not just making an AI feature, but using AI to change how a small product company operates.
Curious if anyone else here is building a consumer app this way.
Does AI make your company feel smaller and more focused, or does it create more things to supervise?
-
1
One thing I found myself wondering while reading this:
How much of the problem comes from people losing memories versus people losing reasons to revisit them?
Those sound similar on the surface.
But they could lead to very different products.
The jump from photo organization to memory management is what caught my attention.
-
1
Yes, this is exactly the distinction I’m interested in.
The memories usually aren’t gone. The photos are still there. What gets lost is the context and the reason to revisit them.
A camera roll preserves raw material, but it doesn’t naturally bring a trip back to life later.
That’s why I think the interesting shift is from photo organization to memory management. Not just “where are the photos?” but “why does this moment still matter, and when should it resurface?”
-
1
That's actually the part I'd be most interested in exploring further.
The moment you shift from preserving memories to deciding when they should resurface feels like it introduces a very different set of product decisions.
I've got a few thoughts on that, but it's probably more than I'd try to unpack properly in a thread.
What's the best email to reach you on?
-
-
Fresh install bugs usually look like UI bugs. This one wasn't.
In Wimemo, a reinstall synced before restore finished, pushed plans: [], and tombstoned the server backup 4 minutes after login.
The dangerous assumption was simple: an empty client on a fresh install is authoritative. It isn't.
The audit found 2 affected founder-controlled accounts, 9 recoverable plans, and 0 third-party users.
The first fix was blunt: stop destructive empty sweeps when the snapshot is empty.
The durable fix was a restore_state handshake: pending, completed, or skipped. Now an empty snapshot can only delete server data after recovery is settled.
Reusable lesson: in a local-first or offline-first product, "empty" is at least two different states: intentionally empty and not-restored-yet. If your sync protocol can't tell them apart, restore is not part of the contract yet.
What client state in your product is currently allowed to delete server data, and how do you prove it's post-restore rather than merely empty?
Comment