Given only a build's output, how do you tell which artefacts were produced once and which need a process at request time?

The question a build output actually answers is not "is this app static?" but "what still has to execute?" Those are different questions, and the file listing answers only the second - if you read it for entry points rather than for file extensions. ## Results versus programs Every artefact in the output is one of two things. A **result** was produced during the build and is finished: a prerendered document, a hashed chunk, a copied image, a manifest. A **program** was produced during the build in order to be executed later: a request handler, a middleware entry, an asset transformer. Both are files on disk, which is why "it is all files" is not evidence of anything. The distinction is whether serving a request means reading bytes or calling code. ## The tells 1. **A server or handler entry point in the bundle.** The most direct signal. Something exports a request handler; something is expected to call it. 2. **Manifest entries resolving to handlers.** A route listed with a handler target and no emitted document will be rendered per request. Counting routes with documents against routes in the manifest gives you the proportion immediately. 3. **Data and form endpoints.** URLs that exist to receive submissions or serve data are code by definition, even when every page around them is prerendered. 4. **A middleware entry.** Code declared to run before route resolution is still code, and it runs on every matching request - including requests for routes that are otherwise finished documents. 5. **A writable cache or regeneration directory.** Its presence says the output expects to be *changed* while running: documents replaced after a window or on demand. A file host cannot do that. 6. **An on-demand asset transformer.** A handler that produces a derivative of an asset at request time, keyed by the parameters in its URL. This is the tell that catches people out, because the rest of the output can be nothing but documents and assets. ## The output that looks static and is not That last one deserves its own paragraph. You can have an output where every route is a finished document, every asset is content-hashed, and a casual reading says "drop this on a file host". Then one handler in the bundle exists to serve asset derivatives, and the markup references those URLs. On a host that cannot run code, those URLs answer with nothing - so the pages arrive, and a portion of their content does not. The lesson generalises: *a page being finished does not mean everything the page references is finished.* Walk the references, not just the routes. ## Reading the output methodically | Found in the output | What it implies | |---|---| | Document for every route, no handler entry | Nothing must execute; the output is a result | | Handler entry plus some documents | Mixed: some routes finished, some rendered per request | | Any endpoint that receives submissions | Code must run, regardless of how the pages were produced | | Writable cache or regeneration directory | Code must run *and* be able to write | | On-demand asset transformer | Code must run even if every page is a document | A good habit when the listing is ambiguous: start the output's own server entry locally and exercise the app. Whatever never reaches that entry is being answered from disk; whatever does is the set of things a host must be able to execute. That turns a guess about file layout into an observation. ## What this does not settle Knowing that code must run is a different question from knowing what shape of host can run it, and a different question again from what a build would look like if you asked for files only. This reading tells you the minimum capability the output demands, and it is deliberately conservative: one handler is enough to make "files only" false. Meta-frameworks also differ in how much they emit by default - some always produce a server entry even when every route turned out to be prerenderable, so the existence of a bundle is weaker evidence than a manifest full of handler targets. Read the manifest before you conclude.