Aller au contenu
apim.one

The blog

The vendor POC is a demo

A proof of concept run by the vendor proves the vendor knows how to put on a demo. How to turn a POC into a trial that really predicts life in production.

The POC is the moment a platform choice tips, and it is the moment best controlled... by the vendor. Its pre-sales team has run the same scenario fifty times: the sample APIs are ready, the policies are written, everything works in two days, everyone is impressed.

That POC proves one thing: that the vendor knows how to run its scenario. It says close to nothing about what awaits you, because everything that hurts was left out of scope.

What a vendor POC never shows

  • Your own APIs. The legacy SOAP with its exotic headers, the backend that takes four seconds to answer, the OpenAPI contract that has been wrong for two years. The POC runs on demonstration APIs that have none of those flaws.
  • Your deployment chain. The demo happens in the console. Your life will happen, one hopes, in a pipeline. The difference between the two is exactly where the products part ways.
  • The second day. The upgrade, a node failing, the certificate expiring, the restore from a backup. None of that fits into two days of demonstration.
  • Your teams. The POC is operated by pre-sales. Production will be operated by your people, with their actual skill level, on a Tuesday evening.

The trial, instead

A useful POC is written by you, run by your teams, on your cases. The vendor assists and unblocks, it does not drive. The scenario fits on one page and it is the same for every candidate, otherwise you are comparing nothing.

The base we use on assignment, to be adapted:

  1. Expose three of your real APIs, including the ugliest. Not the ones you are proud to show: the ones that represent the estate.
  2. Run the complete change through the chain: configuration change in Git, deployment to staging, promotion to production, rollback. Timed, executed by one of your engineers, not by pre-sales.
  3. Break something. Shut down a node under traffic, expire a token, cut a backend. Watch what the consumers see and what the operator sees.
  4. Diagnose a latency. Inject 200 ms somewhere and measure how long the team takes to say where it comes from, with the platform's tooling alone.
  5. Have a consumer subscribe end to end: discovery on the portal, subscription, first request that succeeds. Measure in minutes.

Each point produces a number or a finding, and the comparison grid fills up with facts observed in your own environment, not with the boxes of a brochure.

The most reliable signal

Note what happens when something fails during the trial. It is the most informative moment of the whole selection process: the quality of the error messages, the depth of the documentation once you leave the nominal path, the real competence of the support you were promised.

A product whose demo is brilliant and whose errors are silent is preparing hard nights for you. The opposite is a much better sign.

What the trial costs

Two to three weeks per candidate, with one engineer dedicated half time. It is expensive, and that is why only two finalists sit it, after a first screening on paper.

That cost is to be compared with the cost of getting it wrong: a platform is chosen for five to ten years, and changing it without cutting the traffic is a project of another scale. Three weeks of trial are the best insurance on the market, and that is exactly the protocol we put in place when we support a platform choice.

Published in April 2026.

On the same subject