Teamwork / Creator tools

Developer Product Team Split Calculator

Divide post-fee revenue fairly across your development team.

Golden creator tokens and orange gems beside green steps and a growing plant
Teamwork calculator

Developer Product Team Split Calculator

Divide post-fee revenue fairly across your development team.

Results update automatically
Your result

Enter an amount to calculate.

Distributable revenue = floor(sales × 0.70) · Shares must total 100%

Agree on the revenue pool first

A team percentage is meaningful only when everyone understands the amount being divided. This calculator starts with gross token sales, applies the modeled thirty percent marketplace deduction, and splits the remaining whole-token balance among three contributors. The default roles are lead developer, scripter, and builder, but they represent accounting shares rather than legal ownership. Discuss whether your actual agreement divides gross receipts, post-fee earnings, or profit after expenses. Those definitions can produce very different results for the same sales total.

Follow the order of operations

For 10,000 gross tokens, the modeled distributable pool is 7,000. At shares of fifty, thirty, and twenty percent, the three payouts are 3,500, 2,100, and 1,400 tokens. Deducting the marketplace fee after calculating each person's gross share can introduce inconsistent rounding. Establish one distributable pool, confirm its total, and allocate that amount. The calculator rejects percentages that do not add to one hundred so an accidental typo cannot silently create or remove a share of the team income.

Allocate indivisible tokens fairly

Small pools often cannot be divided exactly. This tool uses the largest-remainder method: calculate each ideal share, assign the whole-number portion, then award remaining tokens to the largest fractional remainders. Ties follow the displayed member order. For a seven-token pool split fifty, thirty, and twenty percent, the resulting allocation is four, two, and one. Every token is assigned. Document the tie rule in advance, or rotate equal-priority recipients across accounting periods if that better fits your team's written agreement.

Account for refunds and shared expenses

The displayed allocation does not create an actual transfer or inspect a group balance. Before paying members, reconcile refunded purchases and any transactions still under review. Decide whether asset licenses, audio commissions, or external services are reimbursed before revenue is divided. Keep those adjustments visible in a shared ledger. If a project is still early, consider reserving a clearly agreed portion for maintenance. Do not withhold an undisclosed reserve after contributors have already completed work under a different arrangement.

Put collaboration terms in writing

Define responsibilities, delivery milestones, acceptance criteria, payment timing, and what happens when a contributor leaves. State who owns the project files and who can authorize changes to the revenue split. Percentages alone do not resolve intellectual property or support obligations. A departing contributor may still have rights under your agreement. If a dispute would have serious consequences, obtain appropriate professional advice rather than expecting a calculator result to establish the parties' rights or settle a contractual disagreement.

Reconcile every distribution

Keep the gross sales report, fee calculation, final pool, percentages, and actual payment identifiers together. Ask members to confirm that the recorded payouts match what they received. Use a consistent accounting period so a late transaction is not counted twice. This example applies the fee once to the entered aggregate; marketplaces that round fees per purchase can produce a different net total. When available, enter or reconcile against the actual post-fee ledger before making irreversible distributions to the team.

Choose an accounting period together

Agree on when a distribution period begins and ends, which statement defines the included revenue, and how later adjustments will be handled. A monthly worksheet is only useful if every member understands the same cut-off. Preserve a reference to the source report so a late purchase is not counted again in the next period. If an earlier sale is reversed after the distribution, record the correction explicitly rather than silently changing another member's current share. The calculator provides allocation arithmetic, while the team agreement determines the treatment of timing differences. A short, consistently maintained ledger can prevent arguments that begin with two people using different definitions of the same total.

Make percentage changes prospective and visible

When someone takes on a larger role, discuss whether the change affects future revenue, a particular deliverable, or an existing ownership arrangement. Record the agreed effective date and preserve the previous percentages with the old distributions. Replacing every historical percentage in a shared spreadsheet makes it difficult to reconstruct what was actually agreed at the time. Before calculating a new distribution, show each member the proposed pool and shares. A numerical total of one hundred percent does not establish consent or resolve contractual rights. It simply confirms that the entered allocation covers the pool without leaving an unassigned portion or assigning more than the available amount.

Explain the rounding rule with a small example

Small distributions are a useful way to teach the largest-remainder rule. Ask each member to calculate an ideal fractional share, take the whole-token portion, and identify the remaining tokens. Compare the remainders and allocate the extras using the published order. The exercise makes it clear why a member can receive a token more than simple rounding might suggest. Keep the deterministic tie policy visible, particularly when equal shares are common. For a long-running team, review whether the same member repeatedly receives an extra token because of ties. Any alternative policy should be agreed and recorded before the distribution, rather than improvised after someone dislikes a particular result.

Find your next tool or idea

Search tools, guides, and Lua resources.

↑ ↓ Browse resultsESC to close

Choose a tool