Build a useful tool with logic people can understand and results they can trust.

Some questions become useful only when readers can enter their own numbers. We design calculators, quizzes, and configurators with documented logic, a clear result, and no hidden use of the information someone provides.

You walk away with a tool someone can complete by keyboard alone, an answer that holds up, and a maintainer who knows what to check when the numbers change.

Person adjusting sliders on a calculator interface that updates a result panel live

Some of the 500+ brands we've worked with

See all references
  • Watsons
  • GAP
  • English Home
  • Joker
  • Axa Hayat Emeklilik
  • Elle

We settle the question, formula, inputs, and edge cases before designing the interface.

  1. Define the decision the tool must support

    Before sketching an interface, we define the single decision or number the tool must help someone reach.

    A one-line statement of what the tool answers.

    AI assist
    Agents can gather the questions people already ask support and search for, which shows whether the answer needs to be interactive at all. A static answer stays a page, and that call is made first.
    Human gate
    Someone on the team signs off on the one-line question before any interface gets sketched.
  2. Document the logic before development

    We document formulas, ranges, assumptions, and edge cases first so the team can explain the reasoning behind every result.

    A documented decision model and input list.

    AI assist
    Edge cases are easier to find when a model runs unusual input combinations in bulk. That gives the reviewer a shorter list of failures to inspect.
    Human gate
    A person checks the formula and its assumptions by hand. An agent can stress-test inputs, but it doesn't own whether the math is right.
  3. Keep only the inputs the result needs

    Every input field must affect the result or support a necessary state. We remove anything the tool does not need.

    A minimal input list with each field's purpose noted.

    AI assist
    Agents can enumerate the inputs a result could use and show which ones actually change the answer. Removing the rest is a decision about what we are willing to collect.
    Human gate
    Whoever owns the tool cuts any field that can't justify its place in the result.
  4. Write every state someone may encounter

    We write the loading, empty, error, and edge-case states alongside the main result so the experience remains clear when inputs or systems fail.

    A content matrix covering every state a user can hit.

    AI assist
    Agents can draft copy for every state, including empty, partial, invalid, and out-of-range. Which states are plausible for a real user is decided by someone who has watched people use tools like this.
    Human gate
    A person walks through every error and edge-case state before calling the state list complete.
  5. Test the full experience with realistic inputs

    We test the prototype with real scenarios and complete the full flow using keyboard-only navigation before calling it finished.

    A working prototype with test results attached.

    AI assist
    Agents can run unusual input combinations at volume and report where the result breaks or looks wrong. Whether a break matters depends on the consequence, so a person reviews the findings.
    Human gate
    Someone tests the prototype with real numbers and a keyboard alone before it's called done.
  6. Give the maintainer a usable handoff

    The maintainer receives the formula, its assumptions, and a clear list of upstream changes that require another review.

    The finished tool plus a maintenance note.

    AI assist
    Agents can assemble the maintenance guide from the logic record and list what to re-check when a rate or assumption changes. The named owner is a person, and they have to accept it.
    Human gate
    The person taking over confirms they understand the formula and what triggers a re-check, before the handoff closes.

Testing more inputs does not settle the formula

We use models to run unusual input combinations and draft early result copy across different score bands. That coverage helps us find breaks sooner. The formula, its assumptions, and the limits of each result still need a person who can answer for them, especially when money, health, or another consequential decision is involved.

You receive the working experience and the documented reasoning needed to maintain it responsibly after launch.

  • a landing page wireframe

    A tested interactive experience

    A live calculator, quiz, or configurator tested with realistic inputs, errors, and edge cases.

  • a style guide with marked rules

    A readable logic record

    A plain-language record of the formula or decision rules behind each result, suitable for non-developers.

  • a measurement note with a small trend line

    A practical maintenance guide

    The pricing, assumptions, and ranges that may change upstream, plus exactly what to update when they do.

We call it done when: someone can complete it start to finish, including by keyboard alone, get an answer that holds up, and your team knows what to check when the underlying numbers change.

Use this method when the reader's numbers or situation change the answer. If everyone receives the same answer, an article will usually serve them better.

A good fit when

  • A calculator's answer changes with the reader's budget, team size, or setup, but a static page cannot account for those inputs clearly.
  • Sales calls and support tickets keep repeating the same situational question, so the team needs a tested answer people can work out for themselves.
  • Your result needs a formula or decision rule that non-developers can review, because presenting the answer as a black box would make it impossible to defend.

Better handled as other work when

  • The honest answer is the same for almost everyone, so a well-written page would serve better than a quiz.
  • The proposed tool asks for personal data that does not change its calculation, so those fields need removing before the interface and data use can be approved.
  • Pricing, ranges, or assumptions will change after launch, but nobody has accepted responsibility for updating the logic and rerunning its tests.
  • Whimsical

    maps every branch of the tool's logic before development starts

  • Outgrow

    builds the working calculator or quiz itself from the approved logic

  • Airtable

    the state-by-state test log, every input combination checked off

  • axe DevTools

    tests keyboard and focus behavior through the tool's live interactive states

  • Notion

    the maintainer handoff: logic, test log, and who owns it next, in one place

Tell us which decision the reader is trying to make. We will check whether their inputs change the answer enough to justify building a tool.
Discuss the interactive content idea
Two people shaking hands on the start of the work

We define the logic, content states, and specification for a developer. Depending on the stack, we can also build a lightweight tool directly.