You own the code: what a Couldi export looks like

The rational concern about any platform that builds software for you is lock-in. What happens when the platform changes pricing, shuts down, or simply stops working for you? If the thing you built only runs there, you have no leverage. You have to accept whatever comes next.

This is a legitimate concern. Platforms that extract retention rather than earn it are common enough that “read the exit terms before you commit” is sensible advice.

So here is what a Couldi export actually contains.

The export tree

Every Couldi project exports as a self-contained directory. The structure looks like this:

your-project/
├── Dockerfile          ← the same one Couldi deploys with
├── nginx.conf          ← ditto
├── spec.md             ← the PRD/TRD your build was planned from
├── package.json
└── src/                ← your application code

Nothing proprietary, nothing platform-specific. The Dockerfile and nginx.conf are exactly the files we use to run your site in production — not versions we generate for export, the actual ones.

The spec.md is the product requirements document and technical requirements document that were written as part of the build process. It documents what the software does, why decisions were made, and what the technical structure is. If you hand this to an engineer, they have context without needing to ask.

The ownership statement, plainly

Our ownership statement is not buried in a terms-of-service footnote. Here it is, in plain language:

This code belongs to you. Couldi claims no license over or rights to exported code. Run it anywhere — the included Dockerfile and nginx.conf are the same ones Couldi deploys with. The “Built with Couldi” link above is appreciated but optional.

The attribution link is optional. The ownership is not ambiguous.

What “no lock-in” means in practice

A statement of ownership is only meaningful if the software can actually run somewhere else. Standard code can. Proprietary runtime dependencies cannot.

Couldi generates standard code — static sites, Node.js apps, Express APIs — that run on any infrastructure that can execute a Docker container. That is most of it. Your hosting provider, your company’s internal infrastructure, a VM you spin up yourself.

Two exits exist and work today:

Download as a ZIP. Every project has an export button. The ZIP contains everything in the tree above. Your computer, your files.

Push to a GitHub repo you control. Connect your GitHub account, pick a repo, and Couldi pushes the full project. The repo belongs to you. If you cancel tomorrow, the code is already there.

“Hand it to your engineers” is not a hypothetical. The spec.md means they have documentation. The Dockerfile means they can run it locally. The code is readable because it was written to run, not to be obfuscated.

Platforms should earn retention

The practical question for any platform is: what keeps you there?

The right answer is that the platform keeps getting better, keeps being useful, and keeps being the easiest way to accomplish something you want to accomplish. The wrong answer is that you stay because leaving is painful.

We build toward the former. The export exists, the ownership is explicit, and the exit is easy on purpose. If we’re earning your continued use, we don’t need the lock-in. If we’re not, you should be able to leave cleanly.

That’s the deal, in full.