Open Source vs. Proprietary: Why We Built Parts of AnimeArray with Open-Source Tools

Sat, 17 Oct 2026 16:56:37 +0000

There's a question we get every time someone finds the site for the first time. It usually arrives about ten seconds after they realise AnimeArray is free:

"So who's paying for all this? What's the catch?"

It's a fair question, and for a while I didn't have a good answer beyond "advertising covers the hosting." That was true but it was the boring half of the story. The interesting half is why we built most of what runs the site ourselves, when we could have assembled the same product out of almost entirely commercial services and shipped it in a fraction of the time.

I've been chewing on that question for long enough that I figured the answer was worth writing down properly — including the parts where we made the wrong call.

What "owning it" actually got us

The first thing you get is the ability to read the code. Not documentation about it — the code.

This sounds obvious once you say it, but I only appreciated it properly during an incident a few months in. Something in the request-handling layer started throwing intermittently. Not consistently enough to be obvious, not rarely enough to ignore. I lost a couple of hours reading the source of the component that was misbehaving, found the logic error, and fixed it myself.

The alternative was a support ticket with a stack trace I didn't fully understand, waiting on a response from someone who would need my description of the problem to even start investigating. That's not a criticism of vendors — it's just a real difference in how long the problem takes to die. On a small project, an hour versus a week is the whole ballgame.

The second thing is exit cost, and this is the one I underweighted for a long time.

Every proprietary tool in a stack is a dependency you don't control. Pricing changes. Features get deprecated. APIs shift under you. The vendor pivots toward a different market. Individually these are survivable. Stacked across a dozen tools, they add up to something you can no longer actually move, even if every individual part is replaceable on paper.

The reason we care is specific: the expensive, hard-won parts of what we built — the recommendation logic that understands what you actually watched, the systems that keep twelve characters sounding like twelve different people — those live in our code, not inside somebody else's product. If we changed direction tomorrow, we'd carry that work with us. That was deliberate, even if I didn't have this vocabulary for it at the time.

The third is predictable cost, which sounds boring until you have to present a budget.

Open source tooling isn't free. It's labour and hardware, both of which you can see coming and forecast. What it avoids is per-seat licences and metered APIs that scale unpredictably and tend to punish you precisely when you start succeeding — which is a genuinely unpleasant property to own.

And the fourth is privacy, though I want to frame it carefully. It's not that open source is more private by some moral property. It's structural. When you run the software, the data stays where you put it. You don't need to publish a policy about what you won't collect, because there's no third party standing in the path to collect it.

The part nobody wants to hear

Open source is not free, and "we built it ourselves" is not a synonym for "we did nothing for it."

Some of the most valuable software in our stack was donated by someone, and I'm grateful for it every day. But the hours we spent configuring, debugging, updating, monitoring and repairing it are absolutely real, and they come out of the same revenue that has to cover hosting and bandwidth. On a small team that's the largest cost we carry, and it's invisible if you only look at the licensing line and conclude we're saving money.

We own the maintenance. Every dependency is something we chose to run, which means somebody is responsible for watching it, updating it, and dealing with the moment an upstream release breaks something we rely on. A company selling commercial software does that work as part of the price. We do it as part of the job. If you're building something small and reading this thinking it's a free shortcut, that's the misunderstanding I most want to correct.

There's a version of this that only works at a certain ratio. If our traffic grew a hundredfold, we'd need to make completely different calls — probably more managed services, more outsourced operations, and a much smaller independent stack. We don't pretend the current approach scales forever. We think it's honest about what it costs and right for where we are today, and those are different questions.

Where we deliberately chose proprietary

I'm not going to pretend open source wins every round, because it doesn't, and an article that only celebrates its own decisions is an advertisement.

We use paid tools in a few categories, and I'd make the same call again:

Things where a support contract is worth more than the licence. When a problem has a clear escalation path and a known owner, it gets solved faster than anything we could diagnose ourselves. That's not a bad thing to buy.

Services with no credible open equivalent at the quality level we need. Rebuilding a search index or a video pipeline in order to avoid a subscription isn't virtue, it's waste. Not everything important is a matter of principle.

Anything where our own time is the scarcest resource and licensing it is genuinely cheaper than building it. This one is easy to get wrong because founders tend to over-value building. Sometimes building is the right call and it's satisfying. Sometimes it's ego with a maintenance bill attached.

The other thing worth saying: we don't treat open source as a purity test. A permissive licence is legal permission, not a guarantee of quality, security, or maintenance. Popularity on a package registry tells you how many people use something. It does not tell you whether anybody is looking after it.

The four questions we ask

When a new tool comes up, we run it through a checklist. It's short on purpose, because a long checklist doesn't get used.

Can we read it? If we can't inspect what we're running, we can't honestly reason about whether it belongs anywhere near a stack that handles user accounts. This is a threshold question — a tool that fails it usually doesn't get a second conversation, regardless of price.
What's the exit? If this vanished tomorrow, how long would it take to replace it? High exit cost on something load-bearing is a decision we make deliberately, or not at all.
Who pays when it breaks? If the honest answer is "we do" and we're not in a position to staff that, we shouldn't choose it. No amount of being right about the long term compensates for a small team quietly becoming the on-call rotation.
Does it compound? Does owning this make the next thing easier to build, or does it create a brand new category of problem? Tools that make later work faster are worth more than tools that are marginally better today.

The real output of this isn't a score. It's that it forces us to be honest about which category a decision falls into, which is where most bad choices actually get made — in the gap between "it's free" and "we can maintain it."

What this actually means for the people who use the site

This isn't infrastructure trivia. It shows up in things people notice.

Because we own the software, we can promise the things that matter and keep them. Everything stays free and usable without an account, because there's no per-user cost to pass on — you can try AnimeArray for as long as you like and never be asked for a card.

It also means we can be straight about what the site is and isn't. It's an independent fan project. It hosts no video. It isn't affiliated with, endorsed by, or connected to any studio, publisher, or licensor. There's no commercial arrangement making any of that awkward to say, and I'd rather be boringly accurate than vaguely impressive.

And it means we can fix things without asking anyone's permission. When something wasn't working well — and things have, repeatedly — we changed it. Nobody had to approve a roadmap.

If you want to see how this reads in practice, the character chats are the part I'm proudest of, mostly because keeping twelve distinct voices distinct is much harder than it sounds and much more satisfying than I expected. The Otaku AI assistant is the other one, and it exists because we kept wanting a thing that didn't exist.

If you're starting something similar

The question isn't open source versus proprietary. Anyone who frames it that way has already decided and is looking for permission.

The question is: do you want to own your dependencies, and are you prepared to pay for that honestly?

If yes, the tooling is the easy part. You'll find the shape of your stack follows fairly quickly from there.

If no — and that's a completely legitimate answer for many projects — you should lean toward managed services, accept the lock-in consciously, and spend the time you saved on the part of the product that only you can build.

The mistake I'd avoid is picking one and then resenting it later. Either position is defensible. Being unable to afford the one you chose is not.

AnimeArray is at animearray.site if you want to see what the outcome looks like. It's free, it needs no account, and every decision I described above is visible in the finished product — including the compromises.