Echo

• 

• 

• 

• 

• 

• 

  Logo

• 

Inspiration

I was saving links everywhere, mostly texting them to myself. I did it for months before I admitted it wasn't working. My own message thread had turned into a junk drawer, and anything I actually cared about was buried a hundred scrolls up.

I couldn't even search for it. Shared links rarely say what the thing is; the preview just says "Instagram," or a username. So I'd scroll back through my texts trying to remember the name of something I never knew the name of. Half the time I'd sent it to my wife instead, and forgotten that too.

Saving a link is easy. But if it just piles up, you've built a graveyard with a nicer font. I also didn't want to file things into folders and tags. That's just handing the work back to me. The app should name it, figure out what it is, and put it somewhere sensible on its own. You can always change it. The AI just has to take the first swing, and be right most of the time.

What it does

Echo isn't a bookmark manager, and it isn't a read-later app. Those are storage. Echo is a resurfacing app: it brings the thing back to you at the moment you'd actually use it.

Saving takes one tap from anywhere on your phone. Share to Echo and you're done. No folder to pick, no tags to invent, no "where does this go." Echo reads the link, gives it a real name instead of "Instagram," and sorts it into a category on its own. If it guesses wrong, you fix it in a tap. It usually doesn't.

Then Echo does the part nobody else does. It learns when you actually use things. If you keep opening workouts in the morning, mornings start showing you a workout. Your Today view is a small, ranked set of what fits right now, not a wall of everything you've ever saved. There's no "done," no unread count, nothing to fall behind on. Come back after a month away and it looks exactly the same as if you'd left yesterday.

For the handful of links you reach for constantly, there's Rotation: a keep-handy strip that sits right on top, zero taps deep. And when you know exactly what you want, search finds it, because now your saves have names you'd actually think to search for.

Save it and forget it. Echo remembers for you.

How we built it

I'm an iOS engineer by trade, so this is a native app, built in Xcode with SwiftUI. No cross-platform framework, no web view wrapped in a shell.

The ideas are mine. AI helped me build them and pressure test them. I used Claude heavily, but not to tell me what to make. I'd bring an idea, argue it out, and let it poke holes in my thinking before I committed any code to it. The thing that made that actually work was writing the design down first. Every subsystem in Echo has a markdown spec that serves as the source of truth, and the rule is that the doc changes first, then the code. That gave the AI a real spec to build against instead of me re-explaining the product every session, and it meant I could move fast without the codebase drifting into something I didn't recognize. I built in weeks what would normally have taken me months.

Supabase is the backbone. Postgres for durable storage, Auth for sign-in, Storage for thumbnails, and Edge Functions for the work that shouldn't live on the device, including the classifier that reads a saved link and decides what it is. Getting that infrastructure right early is what made the rest of the app cheap to build.

Local-first, sync second. The device is authoritative, so everything works offline and the app never feels like it's waiting on a network call. Supabase holds the durable, cross-device copy. The Share Extension writes into the same store as the app, so saving from Instagram hits the same data instantly.

Challenges we ran into

The hardest problem in this project was not a technical one. It was making sure Echo didn't become the exact thing I built it to escape. Every app in this category starts as a good intention and ends as a pile. If you save into Echo for three months and never come back, then I've just built a nicer graveyard, and I'd have failed at the only thing that mattered.

So most of the hard thinking went into two questions. How does the app learn what you actually like, and how does it know when you want it?

I went back and forth on this for a long time. The obvious move is to throw a model at it and let AI decide what to show you and when. I tried that thinking, argued it out, and ended up somewhere more deliberate: AI does the work it's genuinely good at, like reading a link and understanding what it is, while the decisions about what surfaces and when are deterministic and explainable. If Echo shows you a workout at 7am, there's a reason I can point to. That mattered to me, because a recommendation you can't explain is one you can't fix when it's wrong.

Timing was its own puzzle. Knowing that someone likes workouts is easy. Knowing that right now is the moment they'd act on one, and that it isn't just a coincidence, is much harder. It took several redesigns before I had something I trusted, and a lot of the work was learning what signals to ignore.

Then there's the product management side, which was harder than I expected. I was the engineer, the designer, and the only user. Every call was mine, and "this is what I would want" is a sample size of one. The way I handled it was to write down my constraints before I built anything and treat them as non-negotiable. No counters, no streaks, no unread badges, nothing that makes you feel behind. Echo has to look the same after thirty days away as it does after one. Those rules killed several features I liked, which is how I knew they were doing their job.

Accomplishments that we're proud of

What I'm proudest of is being willing to solve the actual problem instead of the one I'd already decided I was solving.

Echo didn't originally have push notifications. My assumption was that people would just open the app when they wanted something, and that a good Today view was enough. That felt obvious to me at the time. But as I talked the design through with Claude and kept pressure testing it, and then started genuinely using the app myself, the hole showed up fast. Nothing brings you back. You have to remember to remember, which is the same failure that made me build this in the first place.

So notifications became the engagement engine, and not as a nagging mechanism. The point is to arrive with something you'd actually want at a time you could actually use it. Working that out and then shipping it is the thing I'm happiest about, because it came from admitting my first answer was wrong.

I'm also proud of how much of this was product work rather than code. Figuring out what Echo should be, who it's for, and why they'd come back took longer than building it did.

And on the technical side, I stood up the whole backend myself. A full Supabase setup, sign-in with both Apple and Google, sync, caching, and a real cross-device story where you sign in anywhere and your saves are simply there. Several of those were firsts for me, and having it all hold together end to end feels good.

What we learned

The biggest thing I learned is that writing the code was never the hard part.

I'm an iOS engineer by trade, so building the app was familiar ground. What wasn't familiar was everything around it. Taking something all the way from an idea to a real product in the App Store means App Store Connect, subscription products, entitlements, pricing, review, and a dozen small flows nobody teaches you because they're not engineering problems. Pricing was a good lesson on its own: some of those decisions are effectively permanent once you make them, so I had to know what Echo was worth and who it was for before I could touch that screen. That forced product clarity earlier than I would have chosen.

The other lesson is the one I'd pass on. You can have a genuinely good idea and still fail to build it, because the idea and the implementation have to be able to meet. The way you architect the thing decides which product ideas are even available to you later. Getting the foundation right early, local-first storage, sync, and infrastructure I trusted, is what made it cheap to keep changing my mind about the product afterward.

And I learned that being your own product manager is a real job. Finding solutions to the actual problem, rather than the problem you assumed you had, is harder and more valuable than any part of the code.

What's next for Echo

Android. The shell is already built and already talking to the same Supabase backend, so the work left is mostly the release flow rather than the app itself. Echo should be wherever you save things, and plenty of people save things on Android.

Automatic groupings. Right now Echo categorizes each save on its own. The next step is noticing patterns across your saves. If you've quietly saved eleven things about Florida over the past month, that's not eleven links, that's a trip. Echo should recognize that on its own and offer to pull them together into one place. Same as everything else in the app, the point is that you never have to create or maintain it. Echo notices, you just say yes.

Ask Echo. Search that works the way you actually think. Instead of scrolling your library, you ask: "I want a pasta meal I can make in under thirty minutes." Echo already understands what your saved links are, so it can answer that. I want it to work by voice as well as text, because voice is where this kind of thing is going, and it's the least effort a person can spend to get something useful back.

Shared groupings. Once groupings exist, the obvious next move is sharing them. You and your partner planning a trip to Spain, both saving into the same place, with one shared collection that builds itself. The same thing works for friends trading recipes, workouts, or memes. Saving is already something people do together, badly, over text. Echo should just do it properly.

Built With

• claude
• ios
• supabase
• swift
• xcode