What we built for Ledgermark
Ledgermark is a concept demo for residual-disability claims software. People on residual disability benefits report what they earn each month, and what they're paid depends on it. That usually means spreadsheets, scanned statements and a lot of waiting.
We built the demo as working software, not clickable pictures. Fifteen screens take a claim from first sign-in to a submitted month, and each month moves through draft, ready, locked and submitted. The figures on screen come from a real calculation engine that's tested before any screen shows a number, because a claims tool that gets the math wrong fails the only test that matters.
Testers get an invite code and a workspace of their own. There's also a public sandbox: every visitor gets a private copy of a sample claim to click through, and the copies are wiped every hour.
Real enough to get an honest reaction
A rough wireframe gets rough feedback. People forgive a grey box and fill the gaps with what they hope the product does, which is exactly the reaction you can't trust. So the parts testers touch need to look and behave like the real thing: real words, real layouts, real numbers, working buttons.
That doesn't mean polishing everything. It means being deliberate about where the realism goes. In Ledgermark the claim screens, the monthly report and the figures are finished. The settings, the edge cases and the admin side are thin, because no tester's answer depends on them.
What a demo should leave out
What the demo doesn't try to answer matters just as much. Ledgermark's demo has no live bank connections, no payment processing and no real customer documents. In the sandbox, uploads, the assistant and sharing are switched off. The heavy production work, from security testing and legal review to data agreements and audits, sits in a second phase that only starts if the first one earns it.
That isn't cutting corners. Those jobs cost real money and take months. Doing them before you know people want the product is how budgets disappear.
The rule we use: fake anything that doesn't change the answer. A stand-in for a bank feed tells you as much about whether people want an automatic income summary as the real connection would. A fake calculation tells you nothing, so the math stays real.
Keep it short
A demo that takes as long as a product isn't a demo. Pick the smallest set of screens that answers your questions, build those well, and resist adding the next feature until testers have seen the first ones. Every week spent on a demo is a week you could have spent learning from it.
It helps to write the stopping point down before you start: these screens, these questions, this many testers. When a new idea comes up halfway through, and it will, it goes on a list for after the first round.
Test it with the right people
Five people who would actually use the product beat fifty who are being polite. For Ledgermark that means claimants and the accountants who help them, not friends of the founder.
Then watch instead of pitching. Give each tester one task, like reporting last month's income, and stay quiet. Where they hesitate is where the product is wrong. What they ask for afterwards is useful, but less useful than where they got stuck.
After every session, write down three things: where they stopped, what they said it was for, and whether they'd use it next month. After five or six sessions the pattern is usually obvious.
When to stop
A demo is finished when it has answered its questions, not when it looks finished. Plan for three outcomes:
- People get it and want it. Move to the production build, and keep the demo as the spec.
- People want the outcome but not this way of getting it. Change the flow and test again. That's cheap now and expensive later.
- People don't care. Stop. That's the demo doing its job, for a fraction of the cost of the full build.
The third is the hardest to accept and the most valuable. Nobody likes hearing that their idea doesn't land. Hearing it after a few weeks of demo work beats hearing it after a year of building.
From demo to product
When the answer is yes, the demo becomes the brief. The screens people used are the screens you build. The questions they asked become the help text. The parts you faked become the integration list, in order of what testers missed most.
Keep the tester notes, too. Six months into the build, when someone argues for a feature nobody asked for, they're the quickest way to settle it.
That's the point of prototyping first. You start the expensive part already knowing what to build, and with proof that someone wants it. If you're sitting on an idea, a sketch or something half-built, tell us where it's at.
