E2E tests for an MVP, in three Markdown files.

Three is the floor. Signup, one critical paid action (the thing the user pays you for, or the thing that proves activation), and billing if money moves. Add a fourth if you have a destructive action that needs to be reversible (delete account, leave team, cancel subscription). A fifth if there is a single dependency on a third-party API that breaks visibly when the upstream service degrades. That is it. Five tests, end to end, in real browsers. The temptation is to write more, because each one feels small, but the maintenance cost of E2E tests scales superlinearly with how many you have. A single founder cannot realistically maintain 30 of them through daily UI churn. The discipline is to keep the suite small enough that you reliably keep it green.

Three reasons compound. First, the test needs a real email inbox the runner can read, because the OTP is delivered out of band; you cannot fake it from inside the browser. Second, OTP screens are commonly built as multiple single-character inputs (six boxes, one digit each), which trips up traditional Playwright fill() because the framework reaches for the first input and the autocomplete logic does not always cascade. Third, OTP timeouts (60-120 seconds for code arrival) blow past the default test timeout in most frameworks, so you need an explicit polling pattern. The reason this one matters most for an MVP is that signup is the front door. If signup breaks, every other test passes against ghost users and you have no idea anything is wrong. Assrt's pattern: create_temp_email at the start, fill the form, wait_for_verification_code (polls every 3 seconds for 60 seconds, defined at /Users/matthewdi/assrt-mcp/src/core/email.ts:67), extract the digits with the seven-pattern regex at email.ts:101, paste them with a clipboard-event hack the system prompt teaches the agent verbatim. That is the whole signup test. Four lines of Markdown.

It is a Markdown file. The format is parsed by one regex at /Users/matthewdi/assrt-mcp/src/core/agent.ts:621 — `/(?:#?\s*(?:Scenario|Test|Case))\s*\d*[:.]\s*/gi` — which splits the file on lines starting with #Case, #Test, or #Scenario, and treats everything between as imperative steps. A first signup test looks like: `#Case 1: Sign up with email`. New line: `Use a disposable email`. New line: `Enter the OTP from the inbox`. New line: `Verify the dashboard heading appears`. The agent reads that, decides at runtime which buttons to click, picks selectors from the live accessibility tree, and runs everything through real Playwright under the hood. You did not import a test framework. You did not write a page-object class. You did not pin a selector. You wrote four lines of English and saved it as scenario.md.

You can. The generated artifacts Assrt produces are real Playwright code, so there is no lock-in either way. The argument for plain Markdown #Cases at MVP stage is purely time. A vanilla Playwright signup-with-OTP test is roughly 60 to 100 lines once you account for the disposable email plumbing, the OTP polling loop, the multi-input paste workaround, the dashboard assertion, and the cleanup. The Assrt equivalent is four lines. At MVP stage you are shipping daily, the UI is shifting, and the maintenance cost of those 100 lines is the part that kills the test. When the UI changes, the agent re-reads the accessibility tree and finds the new button. When the Playwright test breaks, you spend an hour figuring out which selector drifted. After product-market fit, when the UI stabilizes, exporting the recorded scenarios to standard Playwright is a one-shot operation. Before product-market fit, leave the tests in plain English.

The pyramid was written for engineering teams of 5 to 50 with a stable product surface. An MVP is one or two people shipping behavior the team has not yet decided is right. Unit tests freeze internal shapes that are still moving. Integration tests freeze module boundaries that are still moving. E2E tests freeze user-visible contracts (does signup work, does the paid action work, does billing post a charge), and those are the contracts you cannot break without losing users or money. Start at the top of the pyramid. Add tests downward only when you have proof that a specific class of bug keeps biting you and a unit-level test would have caught it. For most MVPs, that day comes 6 to 12 months in, after you have customers and a stable surface. Do not pre-pay for it.

Two choices. The first: run them locally before every push, on the assumption that you push 1 to 5 times per day at MVP stage and the human-loop friction is fine. `npx @m13v/assrt run` against your local dev server, eyeball the result, ship. The second: a GitHub Actions workflow that runs the suite against a preview deployment on every PR, using the runner from the open-source npm package. There is no SaaS gate. The framework is MIT-licensed, the runner ships as a CLI, and the artifacts (video, log, screenshots) write to /tmp/assrt by default and can be uploaded as workflow artifacts on failure. Cost: zero, except the GitHub Actions minutes you would already be spending. Compare that to QA Wolf at roughly $7,500 per month and the math is not close at MVP scale.

Two sources of flake matter at MVP scale. The first is timing flake: the page is not yet rendered when the test tries to click. Assrt addresses this with wait_for_stable, a MutationObserver that polls every 500ms and waits for 2 seconds of zero DOM mutations before continuing (default, configurable, ceiling 30 seconds). The second is selector flake: a button class changed and the test cannot find the element. Traditional frameworks pin selectors at write time and break at run time. Assrt re-reads the accessibility tree on every action, which is slower per test but eliminates the entire category of selector-drift flake. Net effect at MVP scale: a suite of 5 tests reliably stays green through routine UI changes, where the same suite written in vanilla Playwright would need a selector touch-up every other ship. If a test does fail, the run produces a video with an injected red cursor (so you can see exactly what the agent clicked) and a log with the agent's reasoning at every step.

After, at MVP stage. Test-first is a hypothesis-stable practice; an MVP feature is a hypothesis being tested. Build the feature, ship it to one or two users, watch them use it, and only then write the E2E test that locks in the behavior you confirmed they care about. The order matters because writing the test first against a feature you might rip out next week is wasted maintenance debt. The flip side: any feature that ships to users without an E2E test is on a stopwatch. By the end of the week, either it gets a test or it gets ripped out. That is the discipline that keeps the suite small and useful.

Roughly 20 minutes if you have an MVP with signup, a dashboard, and Stripe checkout already built. Step one: `npx @m13v/assrt-mcp` connects the agent to your dev server. Step two: write three #Case files, four lines each, save to /tmp/assrt/scenario.md (the directory and filename layout are at /Users/matthewdi/assrt-mcp/src/core/scenario-files.ts:16-20). Step three: run `assrt_test` against http://localhost:3000 (or wherever your dev server lives), watch the runner execute each scenario in a real browser. Step four: if any test fails, the agent emits a diagnosis with the exact step that broke and a suggested fix. Step five: commit scenario.md to your repo. That is the whole setup. The framework is MIT-licensed and free; the only cost is the LLM tokens for the agent to drive the browser, which run on the order of pennies per test on Claude Haiku.

Three things shift. First, you start adding tests downward into the pyramid because the surface is stable and unit-level bugs become repeat offenders. Second, you start exporting Markdown #Cases to standard Playwright code because the LLM-driven runtime cost stops mattering once you have hundreds of test runs per day. Third, you start branching the suite by environment: local, staging, production, with different scenarios in each. Assrt's outputs are standard Playwright files, which means the migration is mechanical, not a rewrite. The MVP-stage Markdown is a reading-easy front end on top of code that already exists; you keep the underlying tests, you just add a different way of editing them. There is no day-zero break.