Why start with a demo, and what should it prove?
A demo should test the high-risk assumption most likely to change project approval, price, or technical direction. It should not be built merely to look complete. Wavesteam recommends one when an important uncertainty remains; a small change with stable requirements and evidenced interfaces may proceed directly. The question determines the format, duration, and whether any code belongs in production.
To learn whether users understand an approval flow, create a clickable prototype and observe them completing tasks. To learn whether a legacy device protocol works, connect the actual device. To learn whether hundreds of thousands of realistic records can be queried fast enough, build a performance sample with representative distribution. A Figma screen cannot prove an API, and an API script cannot prove usability.
When planning milestones, resources, and acceptance, also compare Which accounts and qualifications should a client prepare before an app release? and Why should a system undergo load and stress testing before launch?; the linked guidance adds context that should be considered in the same decision.
| Demo | What it can answer | What it cannot prove | Exit condition |
|---|---|---|---|
| Paper or clickable prototype | Language, sequence, information hierarchy | Backend, performance, supplier interface | Target users finish named tasks; blockers identified |
| Technical spike | SDK, model, protocol, or conversion feasibility | Full experience, maintainability, market need | Reproducible result or clear failure under critical inputs |
| Vertical runnable slice | One path from interface through data | Whole-system capacity and every permission or exception | Deployable, testable, observable core path |
| Limited business pilot | Adoption and operational capacity | Large-scale growth and long-term economics | Predefined business threshold or evidence to stop or redirect |
A testable demo brief starts with the decision to make, then states hypothesis, input samples, environment, observation method, pass or stop condition, and exclusions. Instead of “AI quotation demo,” it might ask whether confirmed historical orders permit stable extraction of critical process fields, with error types blindly reviewed by domain staff to choose rules, a model, or manual entry. Any accuracy claim names denominator, field weights, and review method.
Use synthetic or de-identified data for personal, medical, financial, or confidential material where possible. Real data needs authority, access, retention, and destruction. A demo is private by default, does not take real payment, and does not share administrator passwords. Code promoted to production still needs security, exception handling, tests, monitoring, and maintainability work.
Wavesteam delivers more than a video: a version or prototype, sample definition, test record, limitations, and recommended decision. The decision can be continue, reduce or change scope, choose another route, or stop. If two routes work, compare latency, review effort, unit cost, lock-in, and failure fallback. If evidence is insufficient, state the next missing proof rather than hide uncertainty in a fixed quote.
A demo narrows later estimates when it proves interfaces and rules and forces redesign when it fails. It cannot guarantee a successful product, but it reveals misunderstanding, unusable data, and external dependency before broad development. A good Wavesteam demo is a bounded experiment with a decision—not a miniature finished product or a sales animation.