Proof of concept

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.

First iteration in front of users
19 hoursFirst iteration in front of users
Total for the validated proof of concept
90 hoursTotal for the validated proof of concept
Client acceptance score
4.5 / 5Client acceptance score

The client

An investment-banking relationship-manager function inside an Asia-Pacific bank, reached through a specialist AI partner. Data spread across a core banking platform, a document repository, spreadsheets and a market terminal.

The engagement

An eight-week proof of concept with a formal acceptance score at the end — deliberately small enough that the client could say no cheaply.

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.

Request demo access

The problem

Banks routinely spend six figures discovering whether a copilot helps a role, and the discovery itself produces a document rather than a working answer. The risk is not that the technology fails — it is that a large validation budget commits everyone emotionally before anyone has seen the thing work, which makes an honest no almost impossible.

What I did

I made saying no cheap. The first iteration went in front of users after nineteen hours, at interface fidelity, because the fastest way to learn whether a copilot fits a workflow is to let the person whose workflow it is press the buttons. Scope was held to four capabilities aimed at one role rather than a platform aimed at a department, and both an experienced and a junior relationship manager were treated as distinct personas, since the value of a copilot differs sharply between someone who knows the answer and someone who does not. The whole thing closed with a formal acceptance assessment, so the outcome was a score the client could act on rather than a positive impression that evaporates by the next budget cycle.

What was built

Four narrow capabilities aimed at a single role — a market copilot answering questions over investment-office documents, a proposal personaliser, a client context builder tracking preferences and insights, and an opportunity radar alerting on market movements — prototyped at interface level first, with both experienced and junior relationship managers as explicit personas.

On the table at the end

  • Interactive proof of concept covering four capabilities
  • Interface prototypes validated with two user personas
  • Formal acceptance assessment

What it changed

Answered a capability question for the cost of an opinion. Ninety hours produced a formally accepted proof of concept instead of a six-figure pilot, and gave the bank an evidenced basis for deciding whether to go further.

How it ran

  1. 01

    Nineteen hours to first contact

    Interface-fidelity iteration in front of real users before any backend investment, because workflow fit is discovered by use, not by interview.

  2. 02

    Four capabilities, one role

    Copilot, proposal personalisation, client context and opportunity alerts — narrow enough to prove, wide enough to matter.

  3. 03

    Two personas, deliberately

    Experienced and junior relationship managers evaluated separately, because a copilot's value inverts between them.

  4. 04

    Map the real data sources

    Core banking platform, document repository, spreadsheets and market terminal identified up front, so the proof of concept knew what it was pretending about.

  5. 05

    Close with a score

    A formal acceptance assessment rather than a warm meeting, so the go or no-go rests on something written down.

Something similar on your plate?

Thirty minutes, no deck. I will tell you whether it is worth doing at all.