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

TermWhat to insist on
Acceptance criteriaThe reconciliation test, written, agreed before work starts
ExportSelf-service, complete, documented format, available from day one
ExitA stated transition window after termination, plus certified deletion
Data processingYou as controller, sub-processors listed, countries named
Plan changesWhether they are an allowance or a new statement of work each time
Audit trailThat rate and rule changes are logged, not only record edits
Run reproducibilityThat a closed period can be recomputed and reproduce what it paid
Incident handlingResponse 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 1Write down the plan — components, rates, qualifications, caps, compression and clawback policy. This drives everything after it
Step 2Model the payout ratio before you buy, so the plan you commission is one you have already tested
Step 3Scope the markets, the migration and the integrations explicitly, as separate line items rather than as assumptions
Step 4Evaluate vendors against stated criteria, and ask for the API documentation before any demo
Step 5Agree acceptance criteria in writing, including the historical reconciliation test for the commission engine
Step 6Sign a statement of work plus a data processing agreement, with export and exit terms named in both
Step 7Parallel run before cutover, then a first live run in preview with the old figures beside the new ones
What we do not sellFixed packages, per-distributor licences, source-code bundles, or anything priced to expire at the end of a call
FAQ

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?

Implementation of your compensation plan, plus the operational software around it and an ongoing arrangement to keep both correct. The plan is the part that is specific to your company, which is why this is a contract rather than a purchase and why a package price is usually a package plan. The practical consequence is that the most important document in the transaction is not the invoice, it is the statement of work: what is being built, what the acceptance test is, what the recurring cost covers, and what happens to your data if the relationship ends.

How do we know when to accept the software?

For an existing company, there is one test that settles it. Take a closed historical period from your current system, load the same orders and the same genealogy into the new engine, run it, and reconcile line by line to what you actually paid. Differences are either bugs or places where your old system was wrong, and both are worth finding before cutover rather than after. For a new company with no history, the equivalent is a set of scenarios you have computed by hand, including your two most awkward cases, agreed in writing before development starts.

What should the contract say about our data?

Four things, and none of them is unusual to ask for. That you can export everything yourself, at any time, without a support request — distributors, both genealogy trees, full commission history, documents — in a documented format. That the export remains available for a stated transition window after termination. That deletion is certified when you ask for it. And a processing agreement naming you as controller, listing sub-processors and the countries data sits in, which both GDPR and POPIA make your obligation regardless of who hosts the system.

Should we pay a fixed price or a monthly fee?

Usually both, and the shape matters more than either number. A build or configuration cost tied to milestones, then a recurring figure covering hosting, support and plan maintenance. The question worth asking is what the recurring fee covers when the plan changes, because compensation plans change and a vendor who treats each change as a new statement of work creates a company reluctant to fix a plan that needs fixing. We do not price per distributor, which sounds cheap early and charges you most at the moment growth is straining everything else.

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 a longer conversation? Open the full enquiry form

required

Prefer email? Write to us at sales@mlmsoftwarepro.com