Presale asset

A demo library instead of a demo

Every presale was building its prototype from scratch. I catalogued fourteen of them by theme so the next one starts from an asset rather than an empty repository.

Catalogued and findable rather than remembered
14 demosCatalogued and findable rather than remembered
Indexed by the capability each one proves
7 clustersIndexed by the capability each one proves
The catalogue references repositories rather than duplicating them
Code stays outThe catalogue references repositories rather than duplicating them

The client

The presale function of a large software services company, where individual teams had each built working demonstrations for their own opportunities and none of them were findable by anyone else.

The engagement

A catalogue pass over the accumulated demo estate: one card per demo, clustered by theme and by the capability it proves.

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

Presale demos are expensive, they are built under time pressure, and they disappear the moment the opportunity closes. Six months later a similar opportunity arrives and someone starts again, because nobody can answer the only question that matters: have we already built something close to this?

What I did

I catalogued rather than collected. Each demonstration gets a card describing what it proves and where the code lives, and the cards are clustered by capability rather than by client, because the reuse question is always 'have we shown a document-AI pipeline before' and never 'what did we build for that client in March'. Code stayed out of the knowledge base entirely — the catalogue points at repositories rather than duplicating them, which keeps the index small enough to read and stops it going stale the first time someone commits. The result is an asset the presale function can start from, and a visible map of which capabilities have a proof behind them and which are still claims.

What was built

A catalogue with a card per demonstration and thematic clusters — financial and software-as-a-service products, document and legal AI, business workflow applications, dashboards and analytics, visualisation and mapping, test automation, and language-model integrations — with the code kept outside the knowledge base and referenced rather than duplicated.

On the table at the end

  • Demo catalogue with a card per demonstration
  • Thematic clusters by capability proved
  • Pointers from each card to the code, kept outside the knowledge base

What it changed

Turned scattered one-off prototypes into a reusable presale asset — so a new opportunity begins by asking which existing demo is closest, rather than by estimating a fortnight of build.

How it ran

  1. 01

    Card per demo

    What it demonstrates, what stack, where the code lives — short enough that writing one is not a project.

  2. 02

    Cluster by capability

    Indexed by what each proves rather than by which client it was built for, because that is how the reuse question is asked.

  3. 03

    Keep code out of the index

    Repositories referenced, not copied, so the catalogue stays readable and does not go stale on the next commit.

  4. 04

    Expose the gaps

    Clusters make it obvious which claimed capabilities have no working proof behind them.

  5. 05

    Make it the starting point

    New opportunities begin with 'which of these is closest' rather than with an empty repository.

Something similar on your plate?

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