The checked list of platform alternatives directory

What to take away

Why one service rarely replaces another

Large services accumulate. A product starts as one thing. It adds messaging, then scheduling, then storage, then a directory. It adds payments through ordinary feature accumulation. Every successful product does this. By the time anyone wants to leave, it does six jobs and the user has stopped noticing five.

A candidate usually does one of those six jobs well. The honest answer to "what can I use instead" is two or three services plus an accepted loss. A directory that pretends otherwise sets up a migration that fails in week three, when someone finds the sixth job was load-bearing.

So the triple: for this job, on this service, these candidates, with these gaps.

The entry

Ten fields, two of them tests the reader runs and one a judgment. A directory of relationships with no checks is a directory of opinions about relationships.

The schema follows the same logic as the fields a single-service entry needs, with a source class and half-life per field.

What changes here is that half the fields decay when either end moves, so an entry's half-life is the shorter of the two.

Checked entries: five incumbents and their candidates

Five incumbents sit in the table below, with a sixth in the worked example after it. Prices are the list rates on vendor pages in early 2026, so check the current number before you decide. The date column is when the row was last checked. Every figure moves.

Every row names a real incumbent and a real candidate. The job column decides the winner, and the same candidate can lose against the same incumbent on a different job.

Worked example: leaving a Facebook group

Say the incumbent is a Facebook group, the job is "host discussion my members can find by search", and the audience is 4,000 people who joined over six years.

Four of these five are real products with public pricing pages. Check the current per-member rate yourself; it changes, and the number that matters is the one on the page the day you decide.

The row doing the work is "does not replace". Discord is a fine answer to "where do we talk" and a poor answer to "where does the archive live". Same incumbent, same members, different job, different candidate.

The "does not replace" line

Write specifics, not warnings. "Does not carry your existing audience" is true of everything and helps nobody. "Import brings post text and dates, and not replies, so a conversation arrives as orphaned statements" is a finding someone can act on.

Four gaps recur across almost every category.

The audience. Almost never transfers. Where a candidate claims it does, find out whether it means contact details or a count.

The archive's addresses. Old links pointing at the incumbent do not follow you. Whether the candidate accepts a redirect, or preserves identifiers, is a real difference between candidates and is almost never mentioned.

The surrounding tooling. Whatever else you connected to the incumbent will not connect to the candidate on day one. This gap closes fastest and should be weighted least.

Other people's habits. Not yours, theirs. This gap ends migrations, and it belongs in the entry as a plain sentence, not a hope.

Import and export are two tests

Import and export are built by different people with different incentives, and they meet in the middle by accident.

Run the incumbent's export first and look at what you actually have: format, completeness, whether authorship and dates survived, whether media came as files or as links back to the service you are leaving. Then run the candidate's import against that exact file, not a sample the candidate provides.

Record both results and the join. The usual outcome is that both features work and the formats do not meet, so the migration needs a conversion step. Whether that step exists, and who wrote it, belongs in the entry.

This is the cost people are really asking about when they ask whether to switch. Naming it as a switching cost rather than an inconvenience makes it comparable with the cost of staying, which is the actual decision.

Keeping the directory current

Two ends move independently, so an entry is rechecked when either does. In practice it inherits the recheck triggers of both services: changes to export, import, pricing tiers, and ownership.

Never let an entry drift into a recommendation as it ages. Per-field checked dates are the fix, and the method runs through the catalog, including the four-source approach to building an entry.

Retire entries rather than leaving them. A triple whose incumbent has closed is history and belongs in an archive section with its dates. A triple whose candidate has closed is actively misleading and should be marked so the day you notice.

What this directory should not do

It should not rank candidates. The axes that decide a substitution are the structural ones in the six-axis comparison method, and they do not order. A candidate better on export and worse on discovery is not further up a list; it is a different trade.

It should not carry a "best alternative" field. The best one depends on the job, and the job is already a column, so the format has answered the question by construction.

It should not call anything a drop-in replacement. For a tool, occasionally true. For a network, never, for the reason the overview of what an alternative has to replace gives: a tool has users, and a network is its users.

Common questions

How many candidates per triple?

Two to four. Beyond that the entry stops being a decision aid and becomes a list, and the marginal candidate is usually one nobody checked. If you can only vouch for two, publish two and say what you did not check.

Can one candidate appear against many incumbents?

Yes, with a separate triple each time. The same service replaces different things to different degrees, and collapsing that into one entry loses exactly the information the format exists to carry.

What if no candidate covers the job?

Say so, in an entry with an empty candidate field and a filled "does not replace" line explaining what is missing from everything available. That is the page no commercial list will publish, and it is often the most useful one in the directory.

Is "keep using it and add something alongside" an entry?

It is often the right answer, and it fits the format: the candidate covers part of the job, the incumbent keeps the rest, and the entry says which parts go where. Recording it as a legitimate outcome stops the directory reading as an argument for leaving.