A founder watches a product demo in which every field accepts a number and a result appears instantly. The interface looks ready. Then someone changes the contract type, keeps the old amounts, and gets another plausible-looking answer. The screen still works, but the meaning of its inputs may have changed.
For a team building a financial tool, that is a useful release question. Can a reviewer reconstruct what the result assumes, or does a polished interface conceal decisions that only the developer understands?
An independent liquidation price calculator offers a concrete case to examine because its estimate depends on contract units, margin, leverage, and maintenance assumptions. Use that calculation workflow as a test specimen, not as an exchange’s authoritative risk engine. The product review starts with what those inputs mean, before asking whether the output looks convincing.
Write the model down before testing the screen
Begin with a short description of the calculation the product intends to perform. Identify the contract, the unit attached to each field, and the assumptions left outside the model. A simplified estimate can be useful without reproducing every exchange rule, provided the interface does not imply that it does.
The linked calculator states that its estimate uses a flat maintenance amount at entry and excludes fees, funding, risk tiers, other positions and collateral haircuts. That makes a useful boundary for a review. A test should check the stated model, then separately assess whether readers can understand its limitations. A matching result is not evidence that excluded costs have somehow been included.
Keep the explanation beside the result during testing. If reviewers need to find a separate document to discover what they just calculated, the release discussion is about communication as well as arithmetic.
Give every input a unit and a valid state
A percentage field deserves more attention than its size suggests. Entering 0.5 to mean half a per cent is different from entering 0.005 as a decimal fraction. The product should make the expected format explicit and test it against a known calculation. Guessing which convention a user intended can conceal errors.
An empty field also needs a deliberate meaning. It might mean that the user has not supplied a value; it should not automatically become a confirmed zero unless that behaviour is part of the specification. Test pasted values, cleared fields, and changes of contract, not just the demonstration’s default settings.
MDN’s documentation for number inputs explains how minimum, maximum and step constraints influence validity. Those browser controls help implement a form, but they do not establish that its financial assumptions are correct. Nor should client-side validation be treated as a substitute for server-side checks where a server processes the input.
Keep one calculation that everyone can reproduce
Use an invented example with easy arithmetic as a shared reference. Suppose a simplified linear-contract model has 1,000 units of margin, 10,000 units of entry notional and a fixed maintenance amount of 50 units. The amount between initial margin and that maintenance requirement is 950 units, or 9.5 per cent of the entry notional.
For a hypothetical long entered at a price of 100, the model therefore reaches that threshold at 90.5, before excluded costs. This is a test case for the stated assumptions, not a live market observation or a recommended trade. A different maintenance convention can produce a different result.
The test record should contain the inputs, expected arithmetic, and observed output. This separates a genuine calculation mismatch from a display problem. Showing 90.50 instead of 90.5 is formatting; silently interpreting a percentage in a different unit changes the calculation.
Treat account modes as different questions
A toggle marked “cross” should not be reviewed as a cosmetic alternative to “isolated”. Ask what additional account information the selected model needs and whether the product actually has it. If not, the result needs a suitably narrow description.
Account mode is part of the model, not proof that the result describes a complete account. Ask the team to document which positions and collateral the calculation receives. A standalone form cannot evaluate balances, obligations, or other positions that were never supplied to it. Its explanation should distinguish inputs it actually uses from account conditions the reader must verify elsewhere.
For a startup’s product review, the practical requirement is to compare like with like. Record the tested contract and account assumptions beside each expected result. An independent model and an exchange account’s current figure are not interchangeable simply because both appear beside the word “liquidation”. If the product cannot reproduce the account’s full calculation, describe its result as the narrower scenario estimate it actually provides.
Test the explanation after the number changes
Return to the original calculator workflow and change one assumption at a time. Record the selected units and margin mode with each result. Ask a colleague to explain the difference without seeing the developer’s notes.
This reveals a separate class of problems. A result may update while an old caption remains, or a screenshot may omit the assumptions that make its number meaningful. A sensible review includes the copied explanation and help text, not only the interactive screen.
Use fictional inputs throughout. There is no need to expose customer balances or open a leveraged position to test whether the interface communicates its own calculation.
Make the release decision about evidence
A useful release record preserves the baseline case, the edge cases, the model’s exclusions, and the unresolved questions. Give an owner to each unresolved issue rather than treating a successful demo as the end of review.
This process does not certify a trading product or make leveraged crypto positions safe. It gives a team a defensible way to say what it tested and what it did not. The strongest interface is not the one that presents the most confident number. It is the one whose number can be traced back to understandable inputs, explicit assumptions, and reproducible checks.
