MLM Platform

The word is a claim, so it should be testable

Every vendor in this category calls its product a platform. The word is meant to signal architecture — an API you can build against, modules you can substitute, data you can take — and it is usually applied to a monolith with a login screen.

Since the term is unhelpful as a differentiator, here is what it means concretely here, with the things you can check during a technical evaluation rather than take on trust.

Test one: does the API cover what the interface covers?

The API here is versioned REST over the whole domain: distributors, genealogy, orders, commission runs, ranks, wallets and payouts, read and write, using the same authorisation model as the back office.

The reason this is the first test is not that most companies build against the API. Most do not, at least at first. It is that API coverage is evidence about the codebase. A system whose API can do everything the screens can do has its logic separated from its presentation. A system whose API covers enrolment and order creation but not commission has its commission logic inside a controller somewhere, and every change you request for the next five years will be priced accordingly.

Ask for the API documentation before the demo. It answers the question that the demo is designed not to.

Test two: can modules be substituted?

Five components, separable:

The honest part of that table is the bottom two rows. Genealogy and commission are the product; a vendor claiming you can swap those is describing a consultancy, not a platform.

What matters is the top three. Companies arriving here almost always have a store they have already tested, a payment provider they have already integrated, and a product catalogue that already lives somewhere. Being told to abandon all three is the most common reason a migration takes nine months instead of eight weeks. The integration pages set out exactly which responsibilities stay where.

Test three: can you leave?

Export is self-service, from the back office, for every entity, in CSV or JSON, with no throttle and no fee. Plus scheduled export to a storage bucket you control, so your own warehouse has a copy without anyone doing anything each month.

This is worth insisting on for a reason that has nothing to do with distrust: a vendor whose export requires their cooperation holds leverage over you for the life of the contract. Not necessarily leverage they use — but it shapes every renewal conversation and every scoping dispute. Get the export tested in the sandbox before signature, and get retention and termination terms in writing.

Numbers, not adjectives

The performance claims in this category are almost entirely adjectival. Real-time genealogy. Lightning-fast commission runs. Enterprise-grade infrastructure.

The figures we will state, and the conditions:

• Genealogy: 250,000 positions, depth 60, sub-second subtree loads. Achieved by server-side paging — the server returns the requested node and its immediate descendants, so cost is bounded by the screen rather than by the organisation.
• Commission run: minutes rather than hours for 100,000 distributors across six bonus types, because volume roll-ups are materialised as orders post rather than aggregated at run time. Runs execute against a snapshot, so the back office stays available throughout.
• Sandbox: a full second environment with synthetic data, for plan changes and integration work, so nothing is tested first in production.

Where a figure depends on your data shape — and several do — the honest answer is that we run it against your own export during evaluation rather than quoting a benchmark from someone else’s organisation.

What this page is not

It is not a claim to be the best platform in the category; that phrase means nothing without a criterion, and where we do compare against named vendors we do it with sourced claims on the comparison pages. It is a list of the questions worth asking any vendor here, including us, and the answers we are prepared to put in writing.