The feature list had forty items, four tabs, and its own color-coding system. It belonged to an ops director at a regional distribution company who had been collecting requirements for an internal dispatch tool the way some people collect souvenir magnets. Every stakeholder had contributed. Nobody had removed anything.

You know how this movie ends: eighteen months, one budget blowup, and a tool that does everything except the thing the dispatcher actually needed at 6 a.m. on a Tuesday.

Here is the good news: rapid prototyping for business software has almost nothing to do with typing faster.

The FDE rapid prototyping playbook comes down to three choices: one user, one workflow, one painful moment. Pick a single named person, the exact task that hurts, and the moment it hurts most. Build only what makes that moment better, put it in front of them inside five working days, and let reality do the requirements gathering. Speed is the output. Refusal is the input.

Rapid Prototyping for Business Software Is a Scoping Discipline, Not a Coding One

Back to the forty items. The turning point in that engagement was not a technical breakthrough. It was a two-hour meeting where the ops director, the senior dispatcher (Dana, twelve years on the radio, immune to nonsense), and a whiteboard fought it out. The rule going in: everything on the list had to answer one question. Does Dana need this to clear the morning line-up without the paper folders?

Thirty-seven items failed the test. Notifications for the VP, an analytics module for quarterly review, single sign-on for a directory three people belonged to: gone, gone, gone. What survived was embarrassingly small, and that is today's loads, who is driving what, and a way to flag a load before it becomes a phone call.

That list of three shipped in four days. The list of forty would have shipped in never.

This is the part people skip when they read about teams that built a prototype in a week. They imagine caffeine and heroic typing. What actually happened is that somebody spent Monday morning cutting MVP scope with a machete, and the rest of the week was carpentry. The cut is the craft. The code is the easy part, which is not something engineers enjoy hearing about their own profession.

The Five Principles

After enough of these weeks, the pattern hardens into five principles. They fit on an index card, which is appropriate, because anything longer would not survive contact with a real client site.

  1. Name the single user. Not "the ops team." Dana. A person with a desk, a shift, and opinions. When you design for one user, every argument about features has a tiebreaker: you go ask her. When you design for "the team," every argument has a meeting instead.
  2. Timebox ruthlessly. Five days, and Friday is a demo, not a timeline negotiation. The deadline is your scope police. Without it, one workflow quietly becomes three.
  3. Fake the hard parts. More below, because this is the highest-impact move in the playbook.
  4. Use real data by day two. Sample data lies. Real data starts the arguments that need to happen.
  5. Demo Friday no matter what. Especially if it is ugly. The demo is the deliverable; the prototype is just its costume.

Principle 3 in practice: the Wizard of Oz backend

The most useful trick in embedded prototyping is building a product where the hard part does not exist yet. The screen says "smart suggestions for tomorrow's schedule." Behind the screen there is no algorithm. There is you, a spreadsheet, and twenty minutes every evening generating tomorrow's suggestions by hand.

This feels like cheating. It is cheating, gloriously. Wizard of Oz prototypes let you test whether anyone wants the suggestion before you spend three weeks building the thing that generates it. Half the time the answer is that the suggestion is fine but the layout is wrong, which is a one-day fix instead of a machine-learning project.

Why real data changes every conversation

With fake data, stakeholders argue about hypotheticals. With real data, they point at the screen and say that load was cancelled last week, so why is it still showing. Now you are having the actual conversation: data quality, the six statuses that exist in the TMS versus the three everyone pretends exist, who owns the fix. Real data by Tuesday means the politics surface while there is still time to build around them.

A Week, Hour by Hour

The week has a shape. It is not rigid, but if your Thursday looks nothing like this, you are probably building too much.

A full Monday-to-Friday plan, with what gets sacrificed each day and why that is survivable, lives in the one-week prototype breakdown. The short version: you sacrifice polish, edge cases, and everyone's pet feature. You never sacrifice the core loop working on real data.

What a Prototype Is Allowed to Skip (and What It Isn't)

A prototype is allowed to skip a shocking amount. Authentication: it runs on one laptop behind a shared login, fine. Multi-user concurrency: Dana is one user and cannot collide with herself. Edge cases: the cancelled load from hell gets handled by a sticky note for another week. Pretty UI: Dana cares that the flag is red and big. She has told you this. Believe her.

Two things are not skippable. First, the core workflow must work end to end on real data. If your demo contains the phrase "imagine this button worked," you do not have a prototype, you have a slideshow. Second, the honest label. Everyone who touches it hears the words "this is a prototype" inside the first minute, because the fastest way to burn the trust a Friday demo earns is letting someone mistake it for a finished product and find a bug on Monday.

Notice the skipped list is also your roadmap. Every item on it is a candidate for the next iteration, argued about with evidence instead of opinions.

After the Demo: The Three Forks

Friday's demo ends one of three ways, and all three are wins. That is the whole economic argument for prototyping fast.

Kill it. Dana shrugs. The painful moment was not where you thought it was. You lost a week and learned something that would have cost a quarter to learn the other way. Write down what you learned, buy Dana coffee, pick a new painful moment.

Iterate it. The most common fork. The loop works but the details are wrong: statuses, sort order, the flag logic. You now own something better than a requirements document, a working thing people can complain about specifically. Complaints are scope, pre-prioritized.

Harden it. Dana refuses to give the laptop back. This is the dangerous fork, because "the prototype became production" is how companies end up running dispatch off a script with no error handling and one maintainer who left two years ago. Hardening is a real project: auth, tests, error handling, the edge cases you skipped, an actual owner. The walk from working prototype to something you can bet a business on is its own discipline, and the 30-day prototype-to-production playbook covers it step by step.

Notice what is missing: the fork where you vanish for six months to build version two before anyone sees version one. That fork is a cliff. The Monday after the demo, you are either iterating with Dana or scoping the hardening. Either way, the plan came from evidence. That is the whole trick.