The prototype was working beautifully. The invoice parser extracted line items, the validation caught duplicates, and the webhook fired on schedule. Then the client changed one field in their CSV export, adding a middle initial to the customer name column, and the entire pipeline choked. No data moved for six hours. Nobody noticed because there were no alerts. The engineer, who had been shipping features at a heroic pace for three weeks, had written exactly zero tests. Not out of laziness. Out of the honest belief that there wasn't time.

This is the central tension of rapid embedded work. The client hired you to move fast. Testing feels like the opposite of fast. It smells like big-company process, like Jira tickets and code-review committees and two-week sprints where nothing ships. But the invoice-parser incident taught a hard lesson: one untested edge case can erase every speed advantage you built. The question isn't whether to test. It's which tests pay rent when you're shipping every few days.

The right testing strategy for rapid development is ruthlessly pragmatic. It covers the paths where failure hurts, ignores the paths where failure is obvious, and adapts weekly as the codebase evolves. It is not a religion. It is a utility bill — you pay for what you use, and you cancel what you don't.

A disciplined testing strategy for rapid development focuses on smoke tests for the money path, lightweight validation for business logic, and just enough monitoring to know when something breaks in production. Everything else is optional until the prototype stabilizes. At a typical mid-size client, this means ten to fifteen focused tests instead of a hundred speculative ones — and a team that still trusts the deploy button on Friday afternoon.

The Real Problem (Speed vs. Safety)

Most testing advice assumes a stable codebase with a dedicated QA team and a release cycle measured in weeks. FDE work is the opposite. The codebase changes daily. The team is usually one engineer. The release cycle is "when the client asks for a demo." Standard test-pyramid wisdom — lots of unit tests, some integration tests, a few end-to-end tests — breaks down when the code under test changes faster than the tests themselves.

The real problem is that tests are code, and code has a maintenance cost. In a prototype, every test is a bet that the code it tests will stay roughly the same. Most bets lose. The engineer who writes eighty tests in week one spends week three updating sixty of them because the schema changed. That's not testing. That's taxation.

The 80/20 Suite

The 80/20 suite is a testing strategy for rapid development that focuses on the tests that catch the most expensive bugs with the least maintenance overhead. It has three layers.

Layer one: smoke tests on the money path. These are end-to-end tests that verify the critical user journey from start to finish. For an invoice parser, the smoke test is: upload a CSV, get valid line items, send a webhook. If that breaks, nothing else matters. One or two smoke tests per critical flow. No more.

Layer two: unit tests for business logic. Not unit tests for framework configuration. Not unit tests for database connections. Unit tests for the code that does math, makes decisions, or enforces rules. The invoice total calculation. The duplicate-detection algorithm. The date-format parser. These tests are valuable because they test logic, not plumbing. Plumbing changes. Logic endures.

Layer three: monitoring and alerts. Not tests in the traditional sense, but safety nets. If the pipeline chokes on a bad CSV, someone should know within minutes, not hours. If the webhook fails three times in a row, a human should be notified. Monitoring catches the bugs that tests miss, and it catches them in production where they actually matter.

What to Skip

The 80/20 suite is as much about what you don't test as what you do. Skip visual regression for internal tools. Skip integration tests for third-party APIs unless you're genuinely suspicious of them. Skip unit tests for code that's obvious and unlikely to change. Skip anything that takes longer to maintain than it would to fix the bug it might catch.

A good heuristic: if you can't explain the bug this test would catch in one sentence, don't write the test. If the test has never failed in two weeks, delete it. Tests are inventory. Inventory costs money.

The Inverted Pyramid

In traditional software, the test pyramid says: lots of unit tests, fewer integration tests, very few end-to-end tests. In rapid prototype work, the pyramid inverts. You want more end-to-end smoke tests because they test the thing the user actually cares about. You want fewer unit tests because the code changes too fast. The smoke test survives schema changes because it tests the output, not the implementation.

This doesn't mean unit tests are useless. It means they're a luxury you earn when the codebase stabilizes. Week one of a prototype is not that time.

Final Thought

The right testing strategy for rapid development isn't about coverage percentages or pyramid shapes. It's about shipping confidently without shipping recklessly. Ten good tests that catch real bugs are worth more than a hundred tests that slow you down. Start with smoke. Add logic tests as the code stabilizes. Monitor everything. Delete what doesn't earn its keep.