scaffold

A scaffold is not a template in the visual sense. It is not a design you fill in. It is a running application with the parts that are tedious and easy to get subtly wrong already present and already tested — routing, authentication, a database client, error boundaries, design tokens, and a test suite that passes.

The distinction that matters is what the model is asked to do. Given an empty directory, a model must invent an architecture: where routes live, how auth is checked, how data access is shaped. It will produce something plausible. Plausible architecture is exactly what fails on the third prompt, when a change has to touch two of those decisions at once and they were never coherent.

Given a scaffold, the model makes a change to working software. That is a smaller task, a more constrained one, and — importantly — a verifiable one, because the scaffold's existing tests are a baseline that a bad change will break.

sup3rapp has three: a marketing site, a SaaS starter, and an internal tool. Each is a real committed codebase whose tests run on every change, so a scaffold cannot rot quietly and take every app generated from it down with it.