Platform prototype
One product, two audiences, one prototype
An annuity platform has an administrator who lives in it all day and a customer who opens it twice a year. I built both, because the demo that shows only one always gets the same question.
- The daily operator and the occasional policyholder, built separately
- 2 journeysThe daily operator and the occasional policyholder, built separately
- Policies, billing, valuations, claims, compliance and the rest of the real console
- 11 areasPolicies, billing, valuations, claims, compliance and the rest of the real console
- Because in annuities the statement is the deliverable
- Export to documentBecause in annuities the statement is the deliverable
The client
A life-annuity provider whose platform has to serve two completely different users — an operations team working policies, billing, valuations, claims and compliance daily, and a policyholder checking a balance and a statement occasionally.
The engagement
A prototype covering the full administrative console and a separate, deliberately narrow customer journey, on mock data throughout.
A working demo of this build exists.
It is not public yet — ask for access, and where the NDA allows I will send a link or walk you through it on a call.
The problem
Financial platform demos usually show one audience. If you show the customer app, the buyer asks who administers it; if you show the console, they ask what the customer sees. Either way the meeting ends on a question rather than a decision, and the answer is always 'that part is straightforward' — which the buyer has heard before.
What I did
I built both and made them look different on purpose. The administrative side is wide, because operations work is wide — policies, billing, valuations, statements, documents, claims, compliance, integrations, reporting, product setup — and a console that shows three tidy screens is not credible to anyone who has done the job. The customer side is deliberately narrow: a dashboard, their policies, their profile, and nothing else, which communicates a product decision rather than an unfinished build. Statement and report export to a document was included because in this industry the artefact the customer keeps is a statement, and a platform that cannot produce one is a platform that has not finished. Everything runs on mock data, stated as such.
What was built
A full administrative console covering policies, billing, valuations, statements, documents, claims, compliance, integrations, reporting, product configuration and an assistant, alongside a separate customer flow limited to a dashboard, policies and profile — with reporting exportable to a document, because in this industry the statement is the product.
On the table at the end
- Administrative console across eleven functional areas
- Separate customer-facing journey
- Document export for statements and reports
- Mock data set covering the policy lifecycle
What it changed
Pre-empted the question that ends most platform demos — 'and what does the customer see?' — by building both sides, and showed that the customer surface is deliberately small rather than an unfinished version of the admin console.
How it ran
- 01
Build the wide side wide
Eleven functional areas in the console, because an operations audience does not believe a three-screen platform.
- 02
Build the narrow side narrow
Dashboard, policies, profile — a deliberate product decision rather than an unfinished admin console.
- 03
Make the two visually distinct
Different layouts for different frequencies of use, so nobody mistakes one for a cut-down version of the other.
- 04
End in a statement
Document export built in, because the statement is the artefact the customer actually keeps.
- 05
Label the data
Mock throughout and said so, so no number in the room gets quoted later as a benchmark.
Other work
All case studies →- Financial planning software
Showing the operator's console, including where the prompts live
A planning platform demo that switches from the customer's view to the vendor's — tenant health, system status, and a sandbox where the AI's prompts are edited. That last screen is the one that sells.
- Healthcare services
The demo that admitted its AI was a rulebook
A treatment-acceptance flow where the assistant suggests answers to a patient's objections. The suggestions came from rules, not a model — and saying so made the demo stronger, not weaker.
- Capital markets
Giving a bilingual site's content back to its editors
Every string on a bilingual market operator's site lived in code, so a comma was a developer ticket. I moved the copy into a headless CMS without letting the market data follow it.
Something similar on your plate?
Thirty minutes, no deck. I will tell you whether it is worth doing at all.