Brad Barrish

One Read serves exactly one article per day, optimized for readability, without all the garbage that litters online reading experiences. If you read it, your streak grows. If you don’t, it’s gone. There’s no archive, no backlog, no “save for later.” Tomorrow brings a different article, and yesterday’s is unrecoverable.

I built this little web app for myself and thought there might be at least a few other people who might want to use it. It’s still a little rough around the edges, but good enough.

My read-it-later queue is a black hole that just makes me kinda hate myself for not getting through it all. Same goes for my hundreds of browser tabs. So I got rid of the queue and built something simple that gets me to read at least one entire article per day. If I miss a day, tough. It just serves me another one the next day. I’ll never know what it was. If break my streak, I begin again. No queues. No self-hatred. Well, at least not as much.

While One Read is a simple idea, it was born out of thinking a lot about how I want to spend my time. Reading is something I love to do and I’ve been doing a lot more of it especially longer form articles and of course books. I’ve also been trying to spend more time creating things, usually in the form of writing or coding things for myself.

There has never been a better time be a creator, regardless of the medium. There has also never been more content to consume, much of which is increasingly being generated by AI. Companies continue to aggressively manipulate us, vying for every second of our attention. When we’re mindlessly consuming, it erodes our attention, our ability to notice and to think critically. I think worst of all, it robs us of the ability to create.

Maybe committing to reading a single article every day can be the beginning of your journey to take back a bit of your time. You gotta to start somewhere.

Now for the nerdier stuff. From a technical standpoint, I wanted to keep things as simple as possible and the first decision I made was to not have a database at all. I already save links to Raindrop.io, so Raindrop is both the inbox and the state store. Saving a link to a collection called “One Read” is the feeder for the app. Each day, a small server picks one unserved link and tags it oneread-served, plus a tag with that day’s date in Raindrop. Those tags are the persistence layer. They make “no going back” a property of the data rather than a UI choice. They survive redeploys and they work across devices. There’s even an admin backdoor: delete the tags and an article re-enters the pool, which came in handy as I was testing.

The rest is deliberately small. A Node/Express server fetches the day’s article and extracts the readable text with defuddle, Steph Ango’s excellent parser, plus a normalization pass that strips out all the publisher junk extraction leaves behind and reduces every article to a small allowlist of clean tags. The frontend is a single HTML file, vanilla JavaScript, no framework, no build step. Type is set in Literata. The streak lives in localStorage. And the whole thing is hosted on Vercel’s free tier, so my costs are literally just the cost of the domain.

I built the initial version of this in a single day. I wrote almost none of the code by hand. I described the product to Claude Fable. I was detailed in my rules, the feel, the parser I wanted and we just iterated. It built, I reacted. The typeface changed a few times. The margins changed a bunch of times. One of the biggest lessons was just how difficult it is to extract only the article body from web pages. I still don’t know if I got all of that right, but it was good enough to ship, but not before asking Codex to take a look at the work Claude and I had done.

I asked Claude to write up its own architecture doc, including a section candidly listing its weaknesses, and I handed the codebase to Codex for review. Codex found several major issues. As I’ve been working with Claude and Codex a lot, this has become a common experience. In every case I can think of, Codex just excels at coding while Claude excels at designing and writing, broadly speaking. Claude can code, but the quality and rigor of its work is not as good as Codex. This seems to be a common experience for people much more experienced than I am.

Deployment was fun! I’d been running the app locally for myself, which worked perfectly. As soon as I put it on Vercel, it crashed instantly. Ultimately, the back-and-forth between Claude and Codex made the code better than either would have produced alone. I probably would not have even been able to launch this without their help. And even if I did, it would have taken me a hell of a lot longer.

Drop me a note and let me know what you think.