Test the baseline before choosing the enhancement https://theholytachanka.com/the-perfect-webstack/ “Works without JavaScript” should identify a task and an expected result. A public article and a logged-in payment form need different baselines. A quick vertical slice exposes the difference before the stack becomes expensive to replace. Three task cards for the same architecture decision Reader task Baseline to demonstrate What an enhancement may add Read and navigate a guide HTML contains the answer and a working next-page link. Local filtering or a reading aid. Submit a support request A server validates the request and returns a clear receipt or error. Inline feedback without a full reload. Save a private account preference Authentication, authorization and durable state work on the server. A faster interface for the same authorized change. An executable acceptance procedure Write one task, its starting URL and the expected destination or receipt. Use a development environment for submissions, not a live payment flow. Disable JavaScript in a fresh browser context. Load the URL directly, follow the link or submit the development form, and record the HTTP outcome and visible answer. Repeat with JavaScript enabled. Confirm that the enhancement keeps the same authorization and validation rules. Use the keyboard. Tab to the action, activate it, inspect focus after any update, then trigger one invalid input. Record browser version, response status and the failure you observed. A screenshot of the happy path cannot prove error handling. Illustrative outcome: a catalogue loads as HTML and its links navigate normally; filtering disappears without scripts, but all entries remain accessible. A prototype form whose only validation lives in JavaScript fails the separate server-validation gate. Static publishing fits the first task; it does not by itself satisfy the second. MDN describes progressive enhancement as a usable baseline with richer capabilities added where available. The test cards above are our own acceptance proposal. Text equivalent: Read a guide → HTML + link → Submit a form → Server validation → Save private state → Authorization + storage Task and starting URL: __________________________ Expected baseline: __________________________ JavaScript-off result: __________________________ JavaScript-on result: __________________________ Keyboard/focus result: __________________________ Invalid-input result: __________________________ Environment and version: __________________________ Observed failure and next decision: __________________________ Original architecture branching map, drawn for the three acceptance tasks; no framework performance claim. https://developer.mozilla.org/en-US/docs/Glossary/Progressive_Enhancement