Will this app still exist in two years?

The question is not whether a tool is good. It is whether committing to it is a decision you will have to make again soon, and at what cost.

Software dies in predictable ways: it runs out of money, it gets acquired and folded in, or the single person maintaining it moves on. Each leaves traces before it happens.

Signals that the lights are on

A changelog with entries from this quarter. The single most reliable indicator. Not a blog, not a Twitter account — a list of what changed and when. Regular small entries beat occasional large ones, because they indicate someone works on this routinely.

Support with recent replies. Open the forum, the Discord, the subreddit, the GitHub issues. You are looking for whether anyone from the company answered anything in the last month. A support channel full of unanswered questions from users is the shape of a product being wound down quietly.

A business model you can state in one sentence. "They charge teams for seats." "They sell a pro tier for power users." "It is a loss leader for their paid product." If you cannot say how the money arrives, the honest position is that you do not know how long it will.

Free with no visible revenue is not automatically doomed — it may be a side project someone enjoys, which can last a decade. But it is a different risk profile from a business, and it should change what you rely on it for.

Signals worth taking seriously

Recent acquisition. The most common outcome for a small tool acquired by a large company is a slow decline: no new features, a migration path to the acquirer's product, and eventually a shutdown notice. Not always, but often enough that acquisition news should prompt you to check your export.

A pivot in the marketing. A tool that used to describe itself as a note app and now describes itself as an AI workspace has usually changed who it is for. That may still include you. It often does not.

Pricing changes that punish existing users. Grandfathered plans quietly removed, a free tier tightened, a feature moved up a tier. These are usually signs of pressure on revenue rather than confidence.

A single maintainer with no succession plan. Common in open source and not disqualifying — much excellent software is one person. But it means the risk is a life event, not a business decision, and no announcement precedes it.

What actually protects you

Not picking correctly. Nobody picks correctly every time, and the cost of trying is that you never adopt anything.

Portability protects you. Specifically:

1. Export before you commit. Run it once, look at the output, confirm you could reconstruct your work from it.
2. Prefer open formats where a choice exists. Markdown over a proprietary rich-text blob; CSV over an internal archive; standard media containers over anything bespoke.
3. Keep the source of truth for critical data somewhere you control, with the tool as a view onto it rather than its only home.
4. Export on a schedule for anything valuable. An export you ran once when you signed up is not a backup of what you have written since.

Open source changes the shape, not the size

An open-source tool cannot be taken away, which is a genuine advantage. It can still be abandoned, and an abandoned codebase you cannot maintain is not much more useful than a shutdown service — unless it is self-hosted and keeps running, which is the actual benefit.

Check the repository the way you would check a changelog: commits in the last quarter, more than one contributor, issues being triaged. A repository with a thousand stars and no commits for two years is a historical artefact.

The realistic goal is not to choose tools that last forever. It is to make each choice cheap to reverse, so that being wrong costs an afternoon rather than a year of work.

A shutdown notice arrives. Now what?

You usually get between 30 and 90 days.

1. Export everything on day one, not in the final week when the servers are overloaded and support has gone.
2. Check the export is complete — attachments, history and comments are the three things most often missing.
3. Choose a replacement second. The urgency is in getting the data out, not in picking where it goes.
4. Keep the raw export even after migrating. Whatever the new tool failed to import is only recoverable from it.