Skip to content

Systems that were expensive to get wrong.

Most of what Kaibre builds is covered by confidentiality. What we can describe is the shape of the problem, the responsibility that came with it, and the fact that we are still running it.

A catalogue where a single record is worth five or six figures.

Kaibre built the production software a luxury-commerce business runs on: individual products valued from approximately US$10,000 to US$500,000, across a catalogue worth tens of millions of dollars.

At those values, accuracy is not a quality-of-life feature. A record that is wrong, stale, or mispriced is a commercial event — not a support ticket. The system is live in commercial use, and Kaibre continues to support and operate it.

Individual product value
$10k – $500k
Catalogue value
Tens of millions
In commercial use
Live

What the system does

Described at the level of structure rather than implementation — nothing here identifies the client, and everything here runs in production.

How a trade moves through it

  1. Listed

  2. Bid or offered

  3. Parties verified

  4. Paid

  5. Fulfilled

Why it mattered

A platform like this has more than one way to be expensive. A pricing or availability error is visible to a buyer immediately. A failed payment path strands a transaction worth more than most annual salaries. A weak verification step lets the wrong counterparty into a trade.

Those constraints shaped the build from the start rather than being hardened in afterwards — and they are the reason the engagement did not end at launch.

Client and implementation details are withheld under confidentiality. No customer data, credentials, infrastructure detail, or commercial terms are described here.

What we take on.

We take on a small number of commissioned builds a year. They tend to look alike: the work is central to how the business makes money, it is expensive because it depends on people who are hard to replace, and the off-the-shelf options solve an adjacent problem rather than this one.

We build the system, put it into production, and keep operating it. The people who designed it are the ones running it a year later.

A good fit

  • A workflow central to how the business makes money.
  • Cost driven by people who are hard to replace.
  • Real consequence — financial, regulatory, or reputational — when it goes wrong.
  • An owner who can describe the process as it actually runs today.

Not a fit

  • Topping up an existing team with engineers.
  • Executing a specification someone else has already written.
  • Fixed-price brochure sites and generic app builds.
  • Building the cheapest possible version of something.