Pre-budget engagement
One prototype, two markets, no budget in the room
A meeting with no project, no budget and no agenda. I brought a day-in-the-life prototype in the client's own language rather than a capability deck, then shipped their feedback as working features.
- Same codebase, rebranded and re-localised
- 2 marketsSame codebase, rebranded and re-localised
- Built from meeting feedback rather than promised in a follow-up
- 4 featuresBuilt from meeting feedback rather than promised in a follow-up
- Client constraints designed in, not bolted on
- On-prem, EU dataClient constraints designed in, not bolted on
The client
A regional bank in Central Europe, corporate banking division. Mid-size institution with hard constraints of its own: on-premise deployment, its own models, data staying inside the EU, a human approving everything.
The engagement
An exploratory session the client explicitly framed as pre-budget, followed by a short build turning their feedback into working features.
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
The bank was explicit that there was no project and no budget — they were preparing for a future decision. That is normally where vendors present a capability deck and nothing happens. And the sharpest person in the room was not asking about AI at all: his question was whether we had done the unglamorous data and integration half of this for another bank.
What I did
I built the demo as one continuous day in the life of a relationship manager, in the local language, with local market conventions, currencies, registries and regulators, because a prototype that speaks the client's dialect reads as understanding rather than as a template. The interface is entirely token-driven, so presenting the same product to an institution in another market was a configuration change rather than a rebuild. After the meeting I split the feedback in two: what could be demonstrated became working features within days, and what could only be asserted — architecture, on-premise deployment, data handling, write-back into their systems — went onto slides, because faking architecture inside a demo is how you lose the technical evaluator you most need.
What was built
A prototype structured as one continuous working day for a corporate relationship manager rather than a feature tour — localised language, currency, registries and regulators — built on design tokens with the language layer separated from logic, so re-skinning for another market is a configuration change.
On the table at the end
- Working bilingual prototype
- Improvement plan split into what the demo can prove and what only slides can assert
- Four new features built from meeting feedback
What it changed
Turned an explicitly pre-budget conversation into a live improvement plan with named follow-ups, and produced a codebase that was re-presented to a second institution in a different market without a rebuild.
How it ran
- 01
One narrative, not seven features
The prototype follows a single persona through one working day, so each capability arrives at the moment it would actually be used.
- 02
Localise before you polish
Language, currency and rate conventions, local company registries and regulators — the details that decide whether a room believes you understand their market.
- 03
Split the feedback honestly
Demonstrable items into the build; architectural claims onto slides with a named owner, and the reference question they asked answered rather than deflected.
- 04
Ship the feedback
Route-to-expert after a client call, a follow-up meeting proposal, a mobile field mode, and a desk-level view one layer above the individual.
- 05
Make it portable
Design tokens, a language layer and market content separated from logic, so a second market costs a day rather than a project.
Other work
All case studies →- Corporate banking
Winning back the last call after two meetings had failed
A long-standing account was one bad meeting from closing. I rebuilt the pitch around the client's own operating numbers and a working prototype, and cut every claim we could not source.
- Private banking
A validated proof of concept in ninety hours
An Asian bank wanted to know whether an AI copilot would help its relationship managers. The first iteration took nineteen hours; the whole validated proof of concept took ninety and scored four and a half out of five on acceptance.
- Insurance
Sequencing the data foundation before anyone bought an AI agent
A financial group wanted AI scoring across five affiliates. I proposed one affiliate, eighteen weeks, and a data readiness report before a single model — because the alternative is an agent trained on data nobody has reconciled.
Something similar on your plate?
Thirty minutes, no deck. I will tell you whether it is worth doing at all.