When the unit economics don't work
Why I shut down AniReco — an embeddings-powered anime recommender — and what I learned about pricing AI features before optimising the model.
I built AniReco because I wanted better anime recommendations than popularity lists. The stack was serious: Gemini embeddings, ChromaDB vector search, IDF-weighted tag scoring, franchise gates, SSE streaming, OAuth, subscriptions, the works.
It worked technically. Users got personalised picks from their AniList. The problem was not the recommender — it was the bill.
Marginal cost per request
Every fresh recommendation that missed cache touched:
- Embedding API calls for titles not yet indexed
- Chroma reads and writes on a single-writer SQLite deployment
- AniList GraphQL for relations and metadata
- Redis for caching, rate limits, and quotas
Usage scaled linearly with curiosity. Revenue did not. Subscriptions and donations covered a fraction of infra at the traffic we reached. I could have raised prices, but the value prop was “free personalised picks” — tightening the funnel would have killed growth without fixing the cost curve.
The honest shutdown
I archived the product instead of letting it bleed. The code stays in the repo. The domain now serves my portfolio. AniReco lives on as the parent brand for Vivaahli and future experiments.
What I’d do differently
- Model the unit economics before the architecture. Price embedding cost per DAU before you index 50k titles.
- Cache aggressively, but count cache misses. Our Redis layer helped, but cold paths were expensive.
- Separate “demo” from “daily driver”. A free tier that only replays cached results might have been viable; unlimited fresh computes were not.
If you’re building consumer AI, the model is not the moat — distribution and margin per request are.