The story behind

Owly Post takes the feeds you already follow, your Substacks, YouTube channels and podcasts, and turns them into a single digest that arrives on your own schedule. It recommends what's worth your time, flags what isn't, and learns from what you actually read.

It was built as part of a 90 day challenge I set myself: build something with AI every day, and end up with a workflow other people can copy. Shipping a real product was part of the deal, and Owly Post is that product. It's the first thing I've shipped end to end myself, with an AI coding agent writing most of the code.

A wish I'd had for a long time

I've wanted one place for everything I follow for years. I read a lot, and all of it lives scattered across a dozen apps and inboxes. Keeping up meant digging through every one of them, so more often than not I just didn't. What I wanted was an overview: one place that keeps track of my resources for me, so I can learn something in the little time I have instead of spending that time searching.

That's what made this the right thing to build. It's a tool I genuinely wanted, and I didn't have to interview a single potential user, because I was the user.

It also broke a long standing deadlock. I'd wanted to build a SaaS for years, and every time I waited for the perfect idea: one big enough to justify the effort. The waiting was the problem. So this time I picked something small and useful to me, and it didn't need to be impressive to be worth shipping.

Two layers, one core

Owly Post is built in two layers. There's an open source core that's free and yours to run yourself, and a cloud version on top of that same core for anyone who'd rather not set any of that up. The product underneath is identical. All the cloud adds is convenience.

The open source part came together fast: storage, feed ingestion, AI summaries, a digest, a scheduler and a UI, in a single day. Then came a week of learning that open source works differently from a private project. Choices I could make once for myself now had to work for anyone running it, so things like the AI model and the mail provider became settings you choose instead of decisions I made for you.

Deleting two days of finished work

To let the cloud reuse the open source project, I first restructured that project: I split it into shared building blocks and set up a pipeline to publish them. It worked perfectly.

Then I sat with it for a day and saw what I'd actually done. Anyone downloading the open source version now got a pile of extra machinery that existed for one reason, which was to make the hosted version's life easier. That's how these projects quietly go wrong. Every change looks reasonable on its own, until the free version isn't a real standalone project anymore, just a leftover of the paid one.

So I threw away two days of finished, working code and went back to where I started. The cloud bends around the core, never the other way around. It was the best decision in the whole build.

What launch taught me

Going live surfaced four problems in three days: a broken deploy, a trial user who burned a month's AI budget in fifteen minutes, a digest of my own that silently never got sent, and endpoints anyone could have called if they'd guessed the address.

All four sat in the areas I knew least about: deployment, cost control, and infrastructure security. None of them were in my plan, because you can only write down decisions about things you know exist. So they turned up as problems instead.

The lesson underneath: write things down before you build them, and make the AI stop and ask instead of guess. That's what keeps you the one deciding, even when you're not the one typing.