XenneX/LLC
All posts

The year I stopped patching and started rebuilding

A patch is cheaper today. A rebuild is cheaper next year. The trick is knowing which year you're in.

#retrospective#indie#architecture#redinfinite#rewrite
The year I stopped patching and started rebuilding

Redinfinite launched in 2019. Infinite Reddit scroller, Tinder-style swipe UI, clean card layout. I was proud of it. Then Reddit changed their API terms in 2023, the math stopped working, and I called it done in last month's post.

Except I rebuilt it this week.

That's the thing about officially retiring a project: sometimes it just means you finally have a clear head to look at it properly.

What "patching" actually looks like

For about two years before I retired Redinfinite, I was patching. The API changes forced me to route around Reddit's official endpoints — scraping, caching, workarounds that worked until they didn't. Each fix bought a few months. Each fix also made the next fix harder, because the workarounds started stacking on top of each other.

I kept the app alive because it had users. Real ones, who would message me when it broke. So I'd patch, it would hold, and I'd go build something else.

The problem with patches is they're invisible debt. Each one feels like a solution. The cumulative cost only shows up when you open the codebase six months later and have to spend an hour just remembering what you were routing around and why.

That's where Redinfinite was when I officially retired it. Not broken — patched into a shape I no longer understood well enough to touch confidently.

The question that actually matters

People frame the patch-vs-rebuild decision as a cost question: how much work is a rewrite versus how many months of patching? That's the wrong frame.

The right question is: do you understand the current system well enough to trust it?

If yes, patch. Knowledge compounds. If you've been in a codebase for years and you still understand it, you're probably faster adding on top of it than starting fresh — even if parts of it are ugly.

If no, you have a different problem. You're not maintaining software, you're doing archaeology. Every change carries unknowns you can't enumerate, which means every patch is higher-risk than it looks. At that point a rewrite isn't just faster — it's safer.

Redinfinite had crossed that line. I wasn't maintaining it. I was guessing at it.

What the rebuild actually was

"Rebuild" is a dramatic word for what I actually did. I kept the core product idea — infinite Reddit browsing, clean card UI, no algorithm — and started the implementation fresh. Clean data layer, proper API abstraction, no buried workarounds from 2022 that I'd forgotten about.

The key difference from the original wasn't the technology (still Ionic/Angular, still the same stack I use everywhere). It was the knowledge state going in. I knew exactly what I needed this time. The first version was me figuring out the product. The rebuild was me actually building it.

That's what most rewrites are: you're not undoing the first version, you're cashing in the learning it cost you.

When to stop patching

There's no universal threshold, but here's the test I use now: can I confidently explain what happens when X breaks? Not in theory — specifically. "If the auth token expires mid-session, it hits this handler, retries once, then redirects to login." That level of specificity.

If I can answer that for the failure modes that matter, I'm still in the system. If I'm hedging, I've lost the thread. Once I've lost the thread on enough things, a patch is just adding another thing to eventually lose track of.

This isn't about code cleanliness or technical debt in the abstract. It's about whether you can reason about your own software. When you can't, patches don't fix the problem — they defer it while making it slightly worse.

The part I didn't expect

The Redinfinite rebuild took a few days. The original took weeks, and I knew the domain less going in. Some of that is tools getting better — AI-assisted development has genuinely changed the pace of solo work. But most of it was knowing exactly what I was building before I started.

The first version of anything is you and the problem getting acquainted. The rebuild is what happens once you actually know each other.


Redinfinite is back — redinfinite.com if you want to see what a second attempt looks like.