Journal

What we learned shipping six apps in a year

I build software alone. Not "small team, mostly me" alone — actually alone, no cofounder, no contractor, no design agency. Over the last year that's meant shipping and maintaining apps across pretty different worlds: a Bible reading app, a pastoral-care platform for churches, a volunteer-event tool, a cattle-herd tracker, and a recovery dashboard for athletes. People sometimes ask how that's possible without burning out or shipping garbage. The honest answer is that it's only possible because I changed how I think about scope, and I got a lot of things wrong before I did.

Lesson one: scope is the only lever that matters

Early on, every app I started wanted to be everything at once. Pilgrim wanted reading plans, social sharing, audio, journaling, and a verse-of-the-day widget on day one. That's how solo projects die — not from lack of skill, but from never shipping a version 1 because it keeps growing before it exists. What actually worked was picking the smallest version of the idea that still solved the real problem, shipping that, and only adding the next thing once real use told me it mattered. Pilgrim's first real release didn't have social features at all. It had reading plans and nothing else, and that was enough to be worth using.

The uncomfortable part of this lesson is that it means saying no to good ideas, not just bad ones. Most of what I cut wasn't bad — it was just not load-bearing for the core problem, and every feature I add is also a feature I now have to maintain alone forever.

Lesson two: one person can't build five different codebases from scratch

This sounds obvious in hindsight, but it took me longer than it should have to admit: the only way to maintain five or six live apps solo is to stop treating each one as a bespoke project. Auth, subscriptions, error logging, the basic app shell — these look the same from one app to the next, whether it's Shepherd on the web or Pilgrim and Regen on iOS, because they should. When I let myself reinvent these per-app "because this one's a little different," I was just paying the same tax five times. The apps that took the longest to get stable were the ones where I'd hand-rolled something I should have reused.

Lesson three: shipping in public means shipping unfinished things, on purpose

A pastoral-care web app and a Bible app for your phone sound like nothing to do with each other, and mostly they aren't — but the workflow of building them is identical: ship something real to a real user fast, even if it's missing things you know it needs. Shepherd's first version didn't have note-visibility layers. Pilgrim's first version didn't have topical search. Both of those turned out to matter, but I only knew that because actual pastors and actual readers used the thin version first and told me what broke. Waiting to ship until it felt complete would have meant guessing at what "complete" meant, and I'd have guessed wrong.

Lesson four: the boring infrastructure work is the actual job

Nobody gets excited about backup jobs, migration scripts, or making sure a Railway deploy actually rolled out cleanly. But across five live apps, the thing that has saved me the most time isn't a clever feature — it's having a repeatable, boring deploy process I trust enough not to double-check by hand every time. The flashy work is maybe twenty percent of what keeps these apps alive. The rest is unglamorous and it's the part that actually determines whether a one-person studio survives past year one.

What I'd tell myself a year ago

Ship smaller than feels responsible. Reuse more than feels creative. And expect that the parts of the app you were most excited to build will matter less than the boring parts you almost skipped. None of these apps are finished — Regen still has features I'm not happy with, Olive is younger than the rest and still finding its shape — but they're alive, real people use them, and a year in, that's the actual measure of whether any of this worked.