There is a written specification. Ask our competitors for theirs

Five documents, written before the code and revised with it. They are plain HTML with one inline style block — no build step, no dependencies, no fonts pulled from anywhere — so each one opens by double-clicking it and will still open in ten years. They go out under NDA, the same way an aggregator sends you its integration pages, and you are welcome to hold us to every line afterwards.

What you get, once an NDA is signed

The library

index.html

Every module, every plan and every design note, with its state in the markup. Start here to see how much of this was written before the code.

The specification

spec.html

Scope, the aggregator boundary, the wallet contract, the data model across 37 collections, the build order, and the M0–M12 tracker with its deliverables and endpoints.

The integration

hub88.html

Both API directions, signing, the ×100,000 wire scale, all fifteen wallet statuses and the go-live checklist. A digest of thirty vendor pages, with the vendor cited as the authority.

The design system

design.html

Twelve sections: direction, tokens, the component kit, 34 player screens, motion, the eight-theme registry, skeletons, localisation, responsive rules and surfaces.

The back office

backoffice.html

The eight groups, the permission table the menu is rendered from, the shape of an audit row, and why staff never see a raw error either.

Why this matters more than a feature list

A specification is the one artefact a technical buyer can check without trusting anybody. Most vendors do not have one to send. It is the cheapest way for a new supplier to be evaluated on evidence rather than on a logo wall it does not have.

Every module has a deliverable list and an endpoint list

Those lists are what “done” is measured against, and a module short of any of the five conditions stays marked partial in the tracker rather than being rounded up.

the contract

The data model is written out in full

Including the indexes that make retries safe, which is the part that is expensive to add later and invisible in a demo.

37 collections

Each non-obvious decision records the failure it prevents

Why the ledger row is written before the balance moves. Why an unmapped category is an error. Why the security score is computed and never stored. A document that only restates what the code does is not worth keeping.

not what, why

Where the documents and the vendor disagree, the vendor wins

The integration document is a digest of the aggregator’s own thirty developer pages and says so. When the two contradict each other, the digest is the bug.

cited

What the documents will not tell you

They describe a platform, not a business. They will not tell you what your licence costs, what your aggregator will charge, whether your market allows what you are planning, or whether your payment rails will hold at volume. Those are your questions to answer, and a vendor who answers them for you on a first call is guessing.

Ask for them on the call, then bring the objection you could not resolve

Book a demo