Buying
Buy MLM Software
You are not buying a product off a shelf. You are either commissioning a build or subscribing to a platform, and in both cases the thing that determines how it goes is written down before anyone starts. This page is the sequence, the contract terms, and the one acceptance test that matters.
What you get
Outcomes operators report after moving onto the platform.
It is a contract, not a purchase
The plan is specific to your company, so somebody implements it. What that means in practice is set out in a statement of work.
One acceptance test that matters
Run the new engine against a closed historical period and reconcile to the cent. Everything else is a checklist by comparison.
Export rights in the contract
Self-service export of everything, in a documented format, from day one and at termination. Get it written rather than described.
Who owns what
Configuration, data and documents are yours without argument. Platform code usually is not, and a licence that survives the relationship matters more.
Payment tied to milestones
Milestones defined by demonstrable output rather than by elapsed time, with the commission engine as its own milestone.
What to walk away from
Pressure to sign on a call, an expiring price, a quote with no migration line, and a refusal to put export terms in writing.
You are not buying a product
There is no version of this software that works out of the box, and the reason is narrow: the compensation plan is specific to your company. It encodes your rates, your qualifications, your caps, your compression rules and your clawback policy, and it changes when your business changes.
So the transaction is either a build, or a subscription to a platform that will be configured for you. Either way the document that determines how it goes is written before anybody starts work.
The purchase sequence
1. Write the plan down. Every component, every rate, every qualification threshold, the caps, the compression rule and the clawback policy. Vendors will quote from this and the quotes only become comparable once it exists.
2. Model the payout ratio. Before you commission a plan, test it. The plan calculator will give you a ratio for a structure in a few minutes, and a plan whose total cost nobody has modelled is a plan you will be renegotiating in year two.
3. Scope markets, migration and integrations as line items. Not as assumptions. Two countries is two tax treatments and two payout positions rather than a translation. Migration is unavoidable for an existing company. Both are routinely absent from quotes that look cheaper.
4. Evaluate against stated criteria. The comparison page sets out eleven, and the demo page turns them into questions for a call. Ask for the API documentation before the demo — it is the one artefact that cannot be prepared for you.
5. Agree acceptance criteria in writing. Including the reconciliation test below. Acceptance defined after delivery is a negotiation; defined before, it is a specification.
6. Sign the statement of work and the processing agreement together. Export and exit terms named in both.
7. Parallel run, then cut over. Both systems computing the same period, reconciled, before anything is posted from the new one.
The acceptance test that matters
Everything else on this page is procurement hygiene. This part is the difference between accepting working software and accepting software that looks like it works.
If you have an existing platform: take a closed period — a month you have already paid — and load the same orders and the same genealogy into the new engine. Run it. Reconcile line by line against what was actually paid.
Every difference is one of two things. A bug in the new implementation, which you have now found before it paid anyone. Or a place where your previous system was wrong, which is uncomfortable and still much better found now.
If you are a new company: the equivalent is a set of worked scenarios you computed by hand, agreed in writing before development starts, and including your two most awkward cases — the ones where components interact, where compression applies, or where a cap binds.
Either way, ask to see the run itself and not a results screen. Results are easy to seed.
What belongs in the contract
| Term | What to insist on |
|---|---|
| Acceptance criteria | The reconciliation test, written, agreed before work starts |
| Export | Self-service, complete, documented format, available from day one |
| Exit | A stated transition window after termination, plus certified deletion |
| Data processing | You as controller, sub-processors listed, countries named |
| Plan changes | Whether they are an allowance or a new statement of work each time |
| Audit trail | That rate and rule changes are logged, not only record edits |
| Run reproducibility | That a closed period can be recomputed and reproduce what it paid |
| Incident handling | Response expectations, and what happens to a payout error |
The two most commonly missing are export and plan changes. Both tend to be described warmly in a call and left out of the document, and both are the terms that determine your position two years later.
Who owns what
Your configuration, your data, your distributor records, your commission history and your generated documents are yours, and any vendor treating that as negotiable has told you something useful.
Platform code is a different question. Most vendors in this category, including us, license the platform rather than assign it, and that is normal — a bespoke codebase you own outright is also a codebase you maintain. What matters more than ownership is that the licence survives the commercial relationship in a defined way, and that your export rights do not depend on the vendor’s goodwill.
If source-code escrow matters to your board, raise it during scoping rather than at signature, because it changes the shape of the arrangement.
Payment structure
Milestones defined by demonstrable output, not elapsed time. “Genealogy loaded and both trees queryable” is a milestone. “End of month two” is a date.
The commission engine should be its own milestone with its own acceptance test, because it is the component whose failure is expensive in a currency other than money.
Then a recurring figure, and one specific question about it: what happens when the plan changes. A vendor who treats every plan change as a new project creates a company that avoids fixing plans that need fixing. The four things that drive the initial number are on the pricing page.
On “packages”
Fixed packages are common in this market and the arithmetic is straightforward: a fixed price requires a fixed scope, and the only fixed part of this software is the plan. So a package price is usually a package plan, offered as a set of parameters somebody already exposed.
That can be the right purchase. It is a materially different product from a platform that will implement your plan, and the distinction is worth establishing before price is discussed. The question that separates them is on the comparison page: can the plan add a commission component the platform does not currently support, and what does that cost.
We do not sell packages, per-distributor licences or source-code bundles, and the reasoning for each is on the pricing page.
What to walk away from
- Pressure to decide on the call, or a price that expires with the meeting.
- A quote with no migration line, when you have an existing platform.
- A refusal to put export terms in writing after describing them enthusiastically.
- No answer to “what does this platform not do”.
- Commission results shown without the run.
- A per-distributor licence sold as the cheap option, without the curve drawn out.
If you buy from us
Scoping first, and it is a conversation rather than a product tour. You will get a written scope with the plan components enumerated, migration and markets as separate line items, and the reconciliation test as the acceptance criterion.
If what you have described is smaller than a build justifies, we will say so during scoping and point you at what fits — including the free and low cost options, and including ones that are not us.
When you are ready, contact us.
At a glance
| Step 1 | Write down the plan — components, rates, qualifications, caps, compression and clawback policy. This drives everything after it |
|---|---|
| Step 2 | Model the payout ratio before you buy, so the plan you commission is one you have already tested |
| Step 3 | Scope the markets, the migration and the integrations explicitly, as separate line items rather than as assumptions |
| Step 4 | Evaluate vendors against stated criteria, and ask for the API documentation before any demo |
| Step 5 | Agree acceptance criteria in writing, including the historical reconciliation test for the commission engine |
| Step 6 | Sign a statement of work plus a data processing agreement, with export and exit terms named in both |
| Step 7 | Parallel run before cutover, then a first live run in preview with the old figures beside the new ones |
| What we do not sell | Fixed packages, per-distributor licences, source-code bundles, or anything priced to expire at the end of a call |
Questions operators ask before they switch
Straight answers on plan mechanics, migration risk and compliance. If yours is not here, ask us directly.
What am I actually buying?
How do we know when to accept the software?
What should the contract say about our data?
Should we pay a fixed price or a monthly fee?
Ready to Transform Your Direct Selling Business?
Send us your plan rules and we will run a live commission cycle against them, on your numbers, before you commit to anything.
- Configured in a sandbox before the call, usually within two business days
- No slide deck and no card — you watch your own plan pay out
- Your plan document stays confidential and is deleted on request
Prefer email? Write to us at sales@mlmsoftwarepro.com