The Prototype Is Not the Product

Here's something I've never gotten used to as a consultant: how much we talk things to death. Meeting after meeting about what we're going to do, before anything exists. With the tools we have now, that approach feels archaic, and honestly frustrating. I'd rather spend my time with a customer on the part only people can do: hearing their pain points and goals, and listening for the shortsighted ask that could be worth a lot more once you factor in what the platform can do beyond what they're asking for. Then I'd rather show them something than describe it.

That's why I love rapid prototyping. I've been building proofs of concept for years, on scoped apps and out-of-the-box applications alike, and it's one of the best tools a consulting team has. But it carries a risk that doesn't get talked about enough: it changes what the customer thinks is possible.

The math in the customer's head

When a customer watches us stand up a working prototype in a few days, the math they do is natural and wrong: if that took a few days, the full build must take a few weeks. AI-assisted tools make prototypes faster every month, so that gap is only going to widen.

A prototype is fast because it leaves out the work that takes the time: RBAC and ACLs, notifications, integrations, error handling, reporting, data migration, performance, testing, training, and documentation. None of it demos well, and all of it is the difference between something that works in a meeting and something that works for an entire organization on a bad Monday.

Three ways to keep expectations honest

1. Name it and scope it out loud. Call it a prototype every time, and say what is not in it. A short "not included" list on the first slide or the demo invite costs nothing and prevents most of the misunderstandings.

2. Use the 80/20 rule. Roughly 80% of the functionality takes 20% of the time. The last 20%, the part that makes it production ready, takes the other 80%. Customers get this quickly once you say it, because they've lived it on their own projects.

3. Use the architect's model. Architecture firms build scale models quickly, and nobody walks through one and assumes the building is finished. Framing, wiring, plumbing, inspections, and trim are where the time goes. A prototype is the model, not the building.

Turn the risk into an advantage

Once the customer has seen what's possible, walk through that "not included" list together and size each item. They go from "a few weeks" to understanding why it isn't, and they hear it from a shared list instead of a defensive consultant.

Fast is a feature, not a promise

Rapid prototyping is worth doing, and I'd encourage every team to lean into it. The credibility we earn with a fast demo is the same credibility we spend if the timeline doesn't match the expectation. Be honest about the rest, and the customer who loved the demo will trust the plan too.