I built a "read later" app in a month because my Pocket backlog was out of control
By May this year I had hundreds of articles saved and was reading almost none of them. Not because I didn't want to. I genuinely wanted to learn this stuff. The problem was that Pocket just sat there waiting for me to open it, and most days I didn't.
So I built MyRundown[dot]io.
The idea is simple: instead of saving things to a queue you have to remember to visit, you save articles throughout the day and get one email the next morning with AI summaries of everything. You already open email. You don't always remember to open another app. That's the whole insight.
Took about a month to build. I'm a developer so the technical side was fine. What I didn't expect was how hard distribution would be. Launched a few weeks ago and traffic is tough to come by. Been writing SEO blog posts targeting things like "pocket alternatives" and "how to clear your read later backlog" and posting in relevant Reddit threads, but rather new at this part
If anyone has been through the early traffic stage and has advice I'd genuinely appreciate it. And if you have a Pocket graveyard problem, give it a try. Free plan at myrundown.io.
What worked for you before you had any organic traffic?
The line that stood out to me was that Pocket didn’t fail because the articles were uninteresting. It failed because returning required a separate habit. I’m building Omphalis around the adjacent problem: when people do come back, they need the article/source/timestamp plus the reason they saved it, not just a summary. Curious whether your early users are asking for more source return paths after the email digest, or mostly just relief from the backlog?
Mostly relief from the backlog, at least so far. The users who've stuck around seem happy to get the summary and move on. Nobody has asked for the original source yet, though I include the link in each digest item in case they want to go deeper.
Your point about the reason for saving is interesting though. I notice I can't always remember why I saved something by the time it shows up the next morning. The article is there, the summary is there, but whatever was in my head when I saved it is gone. Nobody has flagged it as a problem yet but I can see it mattering more as people use it seriously.
What does Omphalis look like in practice? Are you prompting people to add a note at save time or trying to infer it from context?
That's exactly the thing, and it's reassuring that you notice it in your own use. You're right that it doesn't bite early, either. It shows up once people use it seriously and start needing things back. Hard to see until then.
On your question, it's neither, and that's deliberate.
I don't prompt for a reason to save time. When you save something you usually don't know yet why it'll matter, you save because it might. Asking for a note, there is friction for a justification you can't really give.
And I don't try to infer the reason for you. Guessing what was in your head is wrong often enough to quietly erode trust, and once someone catches it being confidently wrong, they stop believing the rest of it.
The bet is that the "why" crystallizes later, when you're actually reading. So that's where Omphalis puts the work: open a saved piece, and it shows you the shape first (the key moments, where it gets dense) so you can re-enter fast, and you mark the lines that land, with a note in your own words if you want. Each mark keeps a path back to that exact spot in the source. So the reason isn't "why did I save this article," it's anchored to the specific passage that mattered, which is usually the thing you actually wanted back.
On summaries: we do them, but only to help you navigate and decide where to drop back in, never to replace the read. Different bet than yours, and I think both can be right for different people. Yours optimizes for throughput and relief, mine for the things people want to return to and reuse.
Would enjoy comparing notes as you see how it lands. Happy to show you the marking flow if you ever want to feel it.
The "why crystallizes at read time" framing is the part I hadn't thought about clearly. My assumption was that the reason lives at save time, but you're right that it's usually fuzzy then and only gets specific when you're actually in the piece.
The distinction you drew is fair. Throughput and relief is basically what my early users want. They're not trying to build a research trail, they just want to clear the backlog without feeling guilty about it. Different job.
Would genuinely be curious to see the marking flow. Take you up on that.
What stood out to me wasn't the traffic challenge.
It was that the product seems to be solving a very different problem than "read later" tools usually claim to solve.
That's the kind of thing that can make distribution look harder or easier depending on how it's interpreted.
That's a fair observation and something I've been thinking about. The product is probably closer to "daily briefing" than "read later"... the saving part is just how content gets into the digest. The thing it actually solves is that most people check email every day and don't check a separate app every day.
But "read later" is where the search intent is, so that's where I've been targeting. Curious what you mean by harder or easier? Are you thinking the audience is different depending on how it's framed?
That's closer to what caught my attention.
The harder-or-easier question is the part I'd spend more time on, but it's probably more than I'd try to unpack properly in a thread.
Happy to continue over email if useful.