The build folder is your exit plan

Imagine that the service publishing your technical work disappears on Friday. Not your repository. Not your domain. The service itself.

Can the site still be online on Monday?

That question is more useful than asking whether a platform supports Markdown, exports, or Git synchronization. Those features tell you something about how content enters the system. They do not tell you whether the public result can survive the system.

This is the reason TidyPress treats build/ as a product boundary. Ownership is not only the ability to recover the sentences. It is the ability to keep serving the interface those sentences became.

The strongest portability test covers both ends: authored source and finished output.

There are two different kinds of lock-in

The first is source lock-in. Your prose, metadata, images, and navigation live in a database or editor that cannot be reconstructed without an export. This is the form most publishing tools now know how to address. They offer Markdown, Git sync, or a download button.

The second is delivery lock-in. You own the source, but the usable site depends on a private renderer, hosted search service, proprietary edge runtime, or account-level configuration. The export gives you ingredients, not the meal.

That distinction becomes important when the publication is more than a blog. A developer site may include product documentation, project pages, references, search, feeds, canonical metadata, and machine-readable context. Rebuilding all of that after leaving a platform is still a migration even when every paragraph was already in Git.

TidyPress makes two promises instead:

1. the repository contains the authored decisions;
2. the build contains the complete deployable result.

The renderer between them is replaceable machinery.

What the repository owns

A TidyPress publish root is intentionally ordinary:

site/
├── tidypress.config.ts
├── src/content/
│   ├── docs/
│   ├── writing/
│   └── projects/
├── public/
└── site/                 # optional presentation extensions

The files describe decisions a project should be able to understand and review: what was written, what collection it belongs to, which routes are public, how the site is branded, and which components the project chose to replace.

There are no generated route modules to preserve as source. There is no remote content identifier hidden in frontmatter. A Git commit can explain the whole change because the meaningful state is in the tree.

This is source portability in its useful form: not merely “we can give you Markdown,” but “the repository already is the canonical publication.”

What the build owns

Running tidypress build creates a static directory containing the public site. The exact files vary with configuration, but the contract includes ordinary HTML and assets plus the discovery surfaces the project enabled:

build/
├── index.html
├── docs/**/index.html
├── writing/**/index.html
├── assets/
├── llms.txt
└── sitemap-index.xml     # when a production site URL is configured

The writing collection also exposes its RSS feed. A local search index is generated after the HTML build, so interactive search does not require a search server. The llms.txt file contains the published Markdown bodies and their public URLs, so agent-readable context does not require a runtime API either.

Cloudflare Pages, GitHub Pages, Netlify, Vercel, an object store, or a plain web server can distribute the same directory. A provider integration may make the upload convenient, but it does not redefine the artifact.

That is output portability: the last successful build remains useful even when the tool that created it is no longer running.

The build folder is not a second source tree

There is a temptation to commit generated HTML “for safety” and then edit it when a deadline is tight. That creates two competing truths.

TidyPress therefore treats build/ as disposable. Delete it and rebuild it. Deploy it and archive it, but do not author inside it. The source tree explains why the output exists; the output proves what the source became.

This separation also makes failures easier to locate:

• if the prose is wrong, change content;
• if a route is wrong, change configuration or collection metadata;
• if rendering is wrong, change a documented presentation boundary;
• if deployment is wrong, inspect how the finished directory was distributed.

Without that boundary, a production fix can turn into an unexplained mutation inside a generated folder.

A useful portability test

You can apply the same test to any publishing system:

1. Clone onto a clean machine. Is the repository enough to reconstruct the publication, or are important choices trapped in an account dashboard?
2. Build without production credentials. Does rendering require access to a private content API or hosted search index?
3. Serve the output with a basic static server. Does navigation, reading, and search still work without the vendor runtime?
4. Move the output to another host. Is changing hosts a copy operation or a content migration?

TidyPress runs packed-package and clean-install checks because a monorepo can pass these tests for dishonest reasons: workspace links, old caches, or files that never reached the published package. The promise matters only on somebody else’s machine.

Portability is a constraint, not a slogan

Choosing a static artifact rules out some shortcuts. Features cannot quietly require proprietary server state. Search must be generated or explicitly provided. Publishing status has to be resolved during the build. Deploy integrations must accept a finished directory rather than taking control of the content model.

That narrower scope is intentional. TidyPress is not trying to replace every dynamic application or enterprise CMS. It is for public technical knowledge that benefits from being durable: documentation, research notes, projects, essays, references, and the record of how work changed.

“No lock-in” is difficult to verify when it describes a company’s intention. A folder is easier to judge. You can open it, diff it, archive it, copy it, and serve it after the original build account is gone.

That is why build/ is more than an implementation detail. It is the exit plan you receive on every successful build.