Commsplit

Problem

The people in an insurance company earn commissions on different things (sales, services sold, premiums, and more), and the rules for each are not simple. Different products pay differently, rates change by role and by target, and a single person's payout can depend on several rules at once. This is the kind of logic that usually lives in one fragile spreadsheet that only one person understands, and that breaks quietly every time a rule changes.

What I built

• A commission engine, not a formula. The rules are data: each rule knows what it applies to (product, service, premium type), who it applies to, and how it pays. Calculating a person's commission means running their activity through the rules that apply, not maintaining a bespoke formula per person.
• A data model designed for the questions behind the payout. Because activity, rules and results are separate and linked, the app can answer not just "how much does this person earn" but "which rules produced it and why", which is what makes it auditable.
• Calculation kept where it can be checked. The heavier maths ran through backend workflows and a calculation layer, so the numbers could be verified rather than trusted blindly.
• Room to change. New rules and new products are added as data, so the business can evolve how it pays without a developer rebuilding the engine each time.

Results

The hard part of commissions is never the arithmetic, it is the number of rules and how they interact. Modelling the rules as data instead of as formulas turned a spreadsheet nobody dared touch into a system the company can read, audit and extend. It is the clearest example I have of why I model the data before building the screens.