Code ownership: what leaving actually costs

Every vendor with an export button will tell you that you own your code. We decided to test the claim the only way that means anything, by moving finished applications onto our own infrastructure and seeing whether they ran.

We took four applications built during our panel testing and gave each a fixed budget of four hours to get running on a plain Linux server with a Postgres database.

Two ran, two did not

The two that ran were standard framework projects: a Next.js application and a Node service with a Postgres schema. Both needed environment variables and a database migration, and both were serving traffic inside ninety minutes. That is a real exit.

The two that did not fail for different reasons. One exported source that depended on platform SDKs for authentication, file storage and scheduled jobs, with no documented way to substitute them. The application started and every meaningful feature returned an error. The other offered no export at all, so there was nothing to try.

The three tiers of ownership

Our testing suggests three honest categories, and we score them accordingly.

Portable. Standard framework code, standard database, no proprietary runtime. You can leave in an afternoon. In our index this describes the front-end specialist and the two developer-first platforms.

Partial. The application code is yours but the platform provides services it depends on. Leaving means rewriting the data and auth layer, which is real work but bounded work, typically a few weeks for a small application.

Resident. There is no export, or the export is a display copy. The work lives where it was made. Three tools in our index sit here.

Why we weight it at only three percent

This attracts more argument than any other decision in our methodology, so here is the reasoning. Most buyers never exercise an exit. Weighting portability heavily would systematically penalise the platforms that non-technical buyers succeed on, in service of a scenario most of them will not encounter.

The counter-argument, which our data editor makes forcefully and which we publish on the relevant review pages, is that the buyers who do need an exit tend to need it under pressure: an acquisition, a compliance requirement, a vendor changing terms. A low weight on a high-consequence risk is a defensible choice and not an obviously correct one.

So the axis is weighted at three percent and reported prominently on every review, including in the machine-readable dataset. If your organisation weights it differently, the raw axis scores are published precisely so you can.

The practical advice

Before you commit anything load-bearing, do what we did. Export the project on day one, while it is small, and try to run it somewhere else. Four hours spent finding out is cheaper than four hours spent finding out later.