A static design can show how an interaction might look. It cannot prove that real data, errors, keyboard use, account permissions, and third-party systems will behave as expected. If a website proposal includes a complex feature, ask whether a small working prototype should be an approval milestone before the full implementation.

Choose the riskiest behavior to test

Do not prototype the whole product. Identify the uncertainty that could change cost or feasibility. For a calculator, it may be the pricing rules and edge cases. For a booking flow, it may be availability updates and confirmation. For a filter, it may be data quality and how results appear with no match. For a customer portal, it may be permissions and authentication. Write the expected inputs and outputs in plain language.

Ask the provider to show the smallest interactive slice with representative data. It may use a temporary interface or limited backend, but it should test the risk it was commissioned to test. A clickable image that always follows the same path is useful for reviewing navigation; it is not proof that the feature works with real rules.

Test ordinary and awkward cases

Run a happy path, an empty result, invalid input, a slow response, and a user who changes their mind halfway through. Test on a phone and with a keyboard if the interaction will be public. The W3C keyboard guidance explains why functionality needs keyboard access; an attractive drag-only design may exclude some users.

If the feature depends on a third-party API, specify whether the prototype uses the real service or a mock, what account or API limits apply, and who pays any vendor charges. If customer data is involved, use suitable test data and identify security review needs. The prototype should also reveal what staff must maintain after launch.

Make the decision explicit

At the milestone, choose to build the feature as scoped, revise and reprice it, replace it with a simpler workflow, or defer it. Record what the prototype proved and what it did not. A successful demo with three sample records does not prove production performance with a large catalog or uninterrupted vendor availability. Add remaining risks to the full-build acceptance tests.

Custom calculators, portals, advanced integrations, and complex product flows are separately scoped work; do not assume they are included in a standard marketing-site quote. ARCHV’s website service page says technical scope and exclusions belong in the proposal. Use the website estimate to describe the uncertain feature and ask for a prototype milestone where appropriate.

A prototype should also answer who will own the finished interaction. Ask where business rules live, who can change them, and how changes are tested. If the only person who understands the logic is the original developer, the business may inherit a maintenance dependency. That may be acceptable, but it should be priced and documented before a full build begins.

Keep the prototype decision and its known limitations with the full-build brief so the production team can test the same risks again before launch.