Boilerplate (starter template)
A working application shipped so that someone else can build a product on top of it — with the architectural decisions already taken. Held here from open-saas, and named as its own class because of what it does to this spoke’s question.
Why it belongs in an architecture wiki
application-architecture asks who decides an application’s structure. A boilerplate is the case where the answer is an absent third party. open-saas arrives with auth providers, a payment processor (three of them), a jobs runtime, an admin dashboard, file storage, an email provider, analytics, an end-to-end test harness, a docs site and two deploy targets already chosen. Each of those is a decision a team would otherwise take deliberately; here they arrive as a bundle, and the reasoning behind them is not in the repository.
The property that makes it usable as a source
Its decisions are inspectable. You can read what a template chose, which is more than can be said for most architecture advice, and it is why a boilerplate is evidence of practice rather than only of marketing. What it does not contain is why — no source here explains a single one of Open SaaS’s choices, and synthesis records that as an open question.
Where it differs from a framework
A boilerplate can be edited away from; a framework’s contract cannot. wasp compiles a spec into an application, so its structural decisions survive every subsequent commit. That is the sharper end of the same move — see wasp.
The genre objection, kept
The hub declined to spin out this spoke on open-saas alone partly on genre: an architecture guide argues a thesis, a template embodies one silently, and the cluster had already excluded a build-along tutorial on that distinction. The objection stands on the record even though the spin-out went ahead, because it names a real difference in what a source can be asked to support.