Rebuild it, or keep paying

Most people find a catalogue like this, get excited, and start building the first thing they recognise. That is the wrong way round. Every app page carries a verdict, a ready-made build prompt, an honest list of what you would lose, and any open-source alternatives that already exist — and the loss list is the part worth reading first. Read the verdict badge first and your brain has already decided; the loss list then becomes a formality you skim.

It is expensive because of the data it holds, the other people already on it, integrations someone spent three years negotiating, or the legal work underneath. An agent can copy code in an afternoon. It cannot copy any of the other four — which is why 86 of every 100 tools are either real work or a bad idea, and why that is useful information rather than a discouraging one.

A note app is judged on the average person’s notes. If your copy holds eight years of history, has four colleagues writing in it daily, and lives on your phone as well, your personal verdict is harder than the badge says. Move it down one level for each of those that is true of you.

Someone has already fixed the bugs you have not thought of, and there is a community to ask when it breaks at 11pm. Building is the right call when your workflow is genuinely strange and nothing off the shelf fits — which is rarer than it feels in the moment you are annoyed.

You are helping me audit my software subscriptions. Be blunt with me.

Here is every paid tool I use:
1. <tool name> - what I use it for - how often I open it
2. ...

For each tool, answer in exactly this format:

TOOL:
WHAT ITS REAL VALUE IS: (the code, the data it holds, the other
  people on it, the integrations, or a legal requirement)
VERDICT: REBUILD or SWAP TO OPEN SOURCE or KEEP PAYING
WHY, IN ONE SENTENCE:
IF REBUILD: the single feature I would actually need on day one
IF SWAP: the open source option, and its biggest real weakness
IF KEEP: the specific thing I would break if I replaced it

Rules for you:
- If the tool holds data I would be damaged to lose, moves money,
  sends email to strangers, or is only useful because other people
  are already on it, say KEEP PAYING and tell me why in one line.
- Do not be encouraging. I would rather hear KEEP five times than
  rebuild something I regret in a month.
- Finish with the ONE tool you would actually start with, and why
  that one rather than the others.

I am considering replacing <TOOL> with something I build myself.

Here is the honest list of what I would give up:
<paste the "what you lose" list, word for word>

Here is how I actually use the tool, week to week. I am including
the boring parts on purpose:
- <specific thing I do, and how often>
- <the one thing I would panic about losing>

Tell me:
1. Which of those losses genuinely bite me given how I use it,
   and which are noise for someone like me. Be specific.
2. The single failure that would hurt most, what it would cost me
   on the day it happens, and how likely it is in the first year.
3. What I would have to do every single month to keep my own
   version alive. List the actual chores, not the principle.
4. Your honest call in one sentence: build it, swap to open
   source, or keep paying. No hedging.

<paste the build prompt from the app's page>

Before you write any code, do these three things in order:
1. Ask me up to five questions about how I actually work. Wait
   for my answers before doing anything else.
2. Write a one page plan: the data model, the screens, and an
   explicit list of what is NOT in version one.
3. Wait for me to reply with the word GO.

Then build version one under these constraints:
- Everything runs on my machine. One single command starts it.
- Store all data in one local SQLite file, and build me a command
  that exports everything to CSV and JSON. I want my data out
  from day one, not as a feature you add later.
- Tell me the exact name and location of that data file so I know
  what to back up.
- No accounts, no login, no cloud services, no API keys.
- Plain readable code over clever code. I am the one maintaining
  this and I am not a developer.
- Write a README that tells me four things: how to start it, how
  to back it up, how to reset it, and what to do when it will
  not start.

Stop when version one runs, and show me the exact command to open it.

Version one works. Now build the thing the paid tool never let me do.

The one thing that always annoyed me about <TOOL> is:
<describe it the way you would complain to a friend>

Do exactly this:
1. Tell me the smallest possible change that fixes that annoyance.
   The smallest. Not the best version, the smallest version.
2. Build only that.
3. Show me which file you changed and explain it to me in three
   sentences, as if I have never read code in my life.

Do not add anything I did not ask for. Do not tidy up or refactor
the rest of the app. Do not change how the data is stored.

# once, ever
npm install -g @anthropic-ai/claude-code

# per project
mkdir my-rebuild
cd my-rebuild
git init
claude

# the moment version one works
git add -A && git commit -m "version one works"

# when a later change breaks everything
git restore .

One line: am I still using the thing I built? If the answer is no, cancel the project rather than the subscription. You will have learned something about yourself that saves the next four weekends.

The catalogue total of 1,093 apps was confirmed on the site itself, and the three verdict figures sum to exactly that. The traffic numbers were re-checked against the site’s public stats page on 17 September 2026 rather than repeated from the guide: it now shows 577,603 page views, 105,552 unique visitors and 11,168 prompts copied across 51 days, against the guide’s 564,050 / 103,951 / 10,901 at 49 days — so the guide was accurate when written and has simply been overtaken. The single-day peak of 49,006 matches exactly. The site is run by one independent developer and funded by sponsor slots; browsing it and copying prompts needs no account.