Services
MLM Software Development
Most of this work is ordinary software engineering. Four parts of it are not, and those four are where projects fail: a commission run is a reproducible batch job rather than a request, there are two trees rather than one, money is not a floating-point number, and correctness is a property of a date rather than of the present.
What you get
Outcomes operators report after moving onto the platform.
The run is the product
Everything else is an interface onto a calculation that must be deterministic, resumable, previewable and reproducible for periods that have already been paid.
Two structures, not one
Placement and sponsorship are separate graphs over the same people. A schema with one parent identifier per distributor has already made a decision that cannot be reversed.
Decimal arithmetic throughout
Rates, volume, splits and rounding computed in fixed-point decimal with a stated rounding rule, because a cent of drift across fifty thousand lines is a support queue.
Correctness is dated
A refund in September changes what August's volume supported. The system needs an answer for August that is still August's answer, not a recomputation.
Records, captured at the time
Retail classification, agreement text, consent and rate changes are recorded when they happen. Every one of them is impossible to reconstruct afterwards.
Custom where it earns its keep
Integrations, internal tools, reporting feeds and genuinely novel plan components. Not a second commission engine, and not a second genealogy model.
Why this is not ordinary web development
Four properties separate this work from the CRUD application it resembles from the outside.
The commission run is a batch job, not a request
A run reads the whole organisation, computes every component in a defined order, applies caps and compression, and produces a line per distributor per component. At fifty thousand positions with an interacting plan that is minutes of computation, not milliseconds.
So it needs a queue, resumable state, and a preview stage that produces the complete output — every line, the total, the payout ratio — before anything posts. A half-finished run is considerably worse than a failed one, because a partial payout is visible to the field and the arithmetic to unwind it is worse than the arithmetic that produced it.
It also has to be reproducible. Re-execute a period closed eighteen months ago, after two rate changes since, and the output must be identical to what was paid. That is only possible if the rule set is versioned with the run rather than referenced from current configuration. The commission page covers how that versioning works.
There are two trees, not one
Sponsorship records who enrolled whom. Placement records where a position sits in the structure that pays. In a unilevel plan they are usually the same shape; in a binary, matrix or any width-capped plan they are not, and spillover makes them diverge permanently on the first placement.
A schema with one parent_id on the distributor row has already chosen one of them, and the other
cannot be reconstructed later from records that were never written. This is the single most common
unrecoverable decision in this category. The genealogy page sets out the
model, including why volume is materialised on write rather than aggregated on read.
Money arithmetic is not floating point
Rates, volume, percentage splits and pool divisions are computed in fixed-point decimal, with the rounding rule stated rather than inherited from a language default. Half a cent of drift on one line is invisible; the same drift across fifty thousand lines is a reconciliation that does not close and a support queue that does not empty.
Where a division does not distribute evenly — a pool across qualifiers, a split across a matching bonus — the remainder goes somewhere defined and recorded, not to whichever row the loop touched last.
Correctness is temporal
This is the property most teams meet late. A refund processed in September removes volume that was counted in August, and that volume may have qualified a rank, filled a leg, triggered a matching bonus and contributed to a pool that has already been divided and paid.
The answer is not to recompute August. August’s statement has to keep saying what August paid, because a distributor will look it up. Instead the unwind becomes dated adjustment lines against the open period, each referencing the original run. Closed periods are records; open periods are where corrections land.
What the discipline actually consists of
| Layer | What it has to be | Where it goes wrong |
|---|---|---|
| Genealogy store | two structures, materialised volume, fast traversal at depth | one tree, recursive reads at render time |
| Plan engine | versioned rule sets, explicit component ordering, preview | rules in application code, recalculated from current config |
| Ledger | append-only, decimal, every line traceable to an order | balances updated in place, no line-level history |
| Compliance records | captured at the moment of the event | derived at reporting time from proxies |
| Tax and payout | per market, with screening before money leaves | one country assumed, then retrofitted |
| Application tier | ordinary, and the largest part by volume of code | usually fine, and usually where the estimate went |
The bottom row is what a demo shows. The top five are what decides whether the system is still correct in year three.
Build, configure, or both
The useful question is not custom or off-the-shelf. It is which layer each requirement belongs to.
Configure the plan. Ranks, thresholds, qualification logic, caps, component ordering, volume values per product, market rules. These are the things that change most often, and they should change without a deployment. The compensation plan page covers what is expressible as configuration.
Build the things that are specific to your business rather than to your category: the integration against the fulfilment system nobody else uses, the internal tool your operations team needs, the feed into the warehouse your analysts already query, the plan component that genuinely has no precedent.
Do not build a second commission engine or a second genealogy model. Two sources of truth for a payout is the most expensive architecture available in this category, and it is usually arrived at by accident — a reporting shortcut that becomes a parallel calculation that eventually disagrees with the engine in front of a distributor.
What “custom” should mean in a proposal
A proposal that describes the whole system as custom development is either quoting a multi-year build or using the word to mean configuration. Both are worth clarifying before signing, and the clarifying question is narrow:
Which specific components are being written for us, where does that code live at the end, and what is the boundary between configuration and development in this scope?
We answer it in writing before work starts, and custom integration code we write is delivered to your repository. The engagement page sets out timelines and cost, and how to evaluate a development partner covers what to check about whoever you end up with, including us.
At a glance
| What the discipline is | Distributed batch computation over a hierarchical data model, with financial-grade arithmetic and an audit obligation, wrapped in a fairly ordinary web application |
|---|---|
| Where teams underestimate it | The run at scale, the second tree, refunds against closed periods, and the compliance records that have to exist from day one |
| What is safe to build custom | Integrations, admin tooling, warehouse and BI feeds, replicated-site templates, and plan components with no existing equivalent |
| What is rarely worth building | A commission engine, a genealogy store, a wallet ledger, or a tax and payout layer, all of which take years to make correct rather than merely working |
| Typical language and platform | A managed relational database with materialised volume, a queue for runs, and a conventional application tier — the model matters far more than the language |
| Non-negotiable engineering properties | Determinism, replay of closed periods, resumable runs, preview before posting, decimal arithmetic, and an append-only audit trail |
| How we work | Configuration on the platform first, custom development only where configuration genuinely cannot express the requirement, with the boundary stated in writing before work starts |
Questions operators ask before they switch
Straight answers on plan mechanics, migration risk and compliance. If yours is not here, ask us directly.
What is MLM software development?
Should we build our own MLM software from scratch?
Why can a general development team not do this?
What does custom development actually mean on your platform?
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