How to Make MLM Software: Architecture and the Order of Work

The hard part is not the tree view. It is not the dashboard, the replicated site or the mobile app.

It is a commission engine that produces the same answer twice — including when re-run months later after the plan has changed — and four records that cannot be reconstructed if you did not capture them from the first enrolment.

Everything else is ordinary software.

The architecture, in four bounded areas

The seams matter more than the technology choices.

1. Identity and placement

Two relationships that beginners collapse into one and should not:

• Sponsor — who introduced this person. A commercial and often permanent fact.
• Placement — where the position sits in the tree. Structural, and in some plans movable.

In a binary these routinely differ, and the difference has money attached. Storing one field for both is the most common early mistake, and unpicking it later means rewriting history you no longer have.

Also here: the genealogy change history. Not the current shape — every change to it, with an effective date. A tree that stores only its present form cannot explain a payment made under a previous form, which is exactly the payment somebody will query.

Genealogy software covers what the tree needs to hold.

2. Commerce

Catalogue, orders, payments, returns, shipping. Mostly conventional, with two direct selling specifics:

Volume held separately from price. Commissionable volume is not the sale price. Tie them and every promotion, tax change and currency difference distorts commission arithmetic. This is the single most consequential data-model decision in the whole system.

A classification on every order, at the moment it is placed. Participant purchase for personal use, participant’s sale to a retail customer, or a direct retail customer order. Three values, recorded at point of sale.

That field is the evidence for where your revenue comes from. It cannot be inferred later — nobody can look at a two-year-old order and determine whether the buyer was a participant purchasing for themselves. Which is why it must exist before the first enrolment rather than before the first audit.

3. The commission engine

A batch calculation over immutable inputs, producing an auditable run. Deliberately not a set of live queries.

Properties it needs:

• Deterministic. Same inputs, same outputs, every time.
• Reproducible after the plan changes, which requires the plan configuration to be versioned and stored with the run rather than read live at execution time. This one requirement eliminates most naive designs.
• Explainable per participant. Not a total — the components, the volume that fed each, and the rules applied. A distributor who cannot see how a figure was reached opens a ticket, and support cost per participant is a margin line.
• Re-runnable in a dry state, so a period can be inspected before anything is paid.
• Adjustment-capable without mutation. Corrections are new entries, never edits to a completed run.

The edge cases are the actual work, and they are where estimates break:

None of these appear in a plan presentation. All of them appear in month three. Commission software covers the engine in more depth.

4. Presentation

Back office, replicated sites, mobile. Reads, never derives.

If a screen computes its own commission figure, you have two engines and they will disagree — generally on the day somebody is comparing them.

The four unrecoverable records

Worth stating plainly, because each one is cheap to add on day one and impossible to add on day four hundred:

1. Order classification at point of sale. Participant purchase, participant’s retail sale, direct retail customer.
2. Consent as an event — timestamp, version of the text, scope, channel. Not a boolean on a user row. A boolean cannot answer “what did they agree to, and when”.
3. Versioned plan configuration per run. Without it, no historical run can be reproduced.
4. Full genealogy change history, with effective dates.

Companies discover these gaps during an audit, a regulatory query or a dispute — the three moments when the gap is most expensive and least fixable.

A realistic build order

Not the order founders want, which is usually the app first.

1. Data model. Placement separate from sponsor. Volume separate from price. Classification on every order. Consent as events. Get this wrong and everything after it inherits the error.

2. Commission engine, against the real plan document. Not the presentation — the document, with every edge case above given a stated answer. If the plan does not define what happens on a return after payout, that is a business decision needed before code, not a technical question.

3. Order capture with classification. The smallest thing that records a correct order.

4. Back office read views. Volume in progress, activity, the commission breakdown with its components.

5. Genealogy views. Genuinely useful, and the part most often built first because it demonstrates well.

6. Replicated sites and attribution. With the one-order-one-owner rule decided by policy before being implemented.

7. Payouts, tax handling, integrations.

8. Mobile.

The ordering principle: anything that writes a record you cannot reconstruct comes before anything that displays one.

Build or buy

Buy the standard parts. Build only what is genuinely specific — usually less than expected.

Buying makes sense when the plan is conventional, which most are. A commission engine for a standard binary, unilevel, matrix or generation plan is a solved problem, and rebuilding it means re-encountering every edge case in the table above at your own expense.

Building makes sense when the plan is genuinely unusual, when the product model does not fit ordinary commerce, or when a regulatory constraint requires control of the stack.

The failure case is building because the plan looks simple. Plans are simple in the presentation and complicated in the exceptions, and the exceptions are the entire cost.

Cost to develop MLM software covers what actually drives the number, and must-have MLM software features covers the module list ranked by what breaks without it.