Build vs Buy: Should You Write Your Own Royalty Engine?

Compare building a royalty engine with buying software: define the scope, test contract calculations, and assign long-term costs and responsibilities.

Building a royalty engine gives you a software product to own, not just a calculator to finish. Buying one gives you a product and supplier to evaluate, not a transfer of responsibility for your royalty results.

For a label or distributor, the useful question is therefore narrower than “Can we build this?” It is: Which parts must we control ourselves, and can we support them through future reporting periods?

This guide compares engineering ownership with buying dedicated software. It is a decision framework, not a claim that one route is cheaper, faster or suitable for most catalogs.

Start with scope, not a generic development estimate

Separate the calculation engine from the surrounding operation. Does your proposed build cover source-file ingestion, catalog matching, contract configuration, royalty calculation, statement generation, access controls and payment administration? Mark each item as included, excluded or dependent on another system. Catalog delivery to platforms is a separate requirement from importing royalty sales reports.

The UK government's purchasing-strategy guidance recommends assessing user needs, lifecycle costs and organizational capability before choosing to build, buy or combine the two. It also recommends testing a difficult, small problem when evaluating a purchase. This is general technology guidance for government, not a rule binding record labels or a music-industry cost benchmark.

Published build-vs-buy figures need context. Zenskar's billing-software article, published in March 2024, discusses developer costs, team size, timelines and overruns. That is a billing vendor's commentary, not a royalty-engine estimate for your business. We do not use those figures to forecast a royalty project, or assume that royalty software is necessarily more expensive to build than billing software.

Instead, ask each proposed delivery team to estimate the same defined scope, with assumptions and exclusions attached.

Define the royalty problems the engine must handle

Before selecting an architecture, write down examples your finance team can explain independently. The following are recommended acceptance tests, not a claim that every catalog has every requirement.

Contract calculations and balances

Choose representative agreements and specify their calculation bases, participation shares, royalty rates, deductions, escalation thresholds, currencies and any recoupment or cross-collateralization provisions. Have an appropriately qualified person resolve ambiguous contract language before it becomes a software rule.

For each test, distinguish the royalty earned on a sales line from the closing balance after other entries and from an eventual bank payment. An incorrect calculation may affect a statement or a later payment; it does not establish that money has already moved.

Qlero's calculation guide illustrates why scope matters: its documented sales-row calculation uses a royalty base, participation percentage and adjusted rate, while statement balances also reflect items outside that row calculation. That describes Qlero's documented model, not every agreement or engine.

Input files and exception handling

Use the actual provider files you expect to process, with confidential information removed where necessary. Specify how the proposed system should handle missing identifiers, ambiguous matches, duplicate submissions and invalid amounts.

Include at least one rejected row in the demonstration. Ask who investigates it, what evidence is retained and whether correcting it requires a new import or recalculation. Do not accept “supports imports” as an answer to those narrower questions.

Reproducibility, access and security

Define the evidence you need to explain a result: source inputs, interpreted terms, configuration used, calculation output and subsequent corrections. Then ask the team to demonstrate which records exist, who can change them and how they can be exported.

A locked reporting period, an exported statement and a history of user changes are different controls. Specify the required controls for either route; do not assume a purchased product includes a complete audit log or that a custom build automatically meets a contractual audit requirement.

For web-application security, OWASP ASVS provides requirements and a basis for testing technical security controls. Your security reviewer can use it when defining an assessment. It is not a royalty-calculation standard, and citing it here does not certify Qlero or another product.

Compare ownership costs over the same period

Use a cost worksheet with separate lines for implementation and ongoing operation. These are planning prompts, not price estimates:

• Build: requirements work, finance input, engineering, test cases, hosting, security assessment, monitoring, support, documentation and handover.
• Buy: quoted subscription or license charges, required plans or add-ons, setup, data preparation, configuration, integrations, training and internal operation.
• Both: investigation of exceptions, approval of results, changes to requirements and a practical exit plan.

Record which items are included in a quote, which remain estimates and who pays when assumptions change. Compare a common time horizon and workload; do not compare a prototype budget with the cost of an entire production service.

A supplier may maintain the purchased application under its terms, but your organization still needs oversight. A 2021 Government Digital Service discussion makes that distinction across build, buy and combined approaches. It is a general governance principle, not evidence of a particular vendor's service level.

Build vs buy at a glance

Use these six dimensions as questions to resolve, not market averages or a scoring system that makes buying win by default.

Five questions that clarify the decision

1. Who owns the engine after launch? Name both technical and finance owners, including who handles incidents when the original developer is unavailable.
2. What happens when a result is wrong? Describe review, correction and communication before treating an error as a payment event. Test the proposed workflow.
3. Which agreement changes need code? Try a representative new condition. Determine whether it is configuration, supported extension or engineering work; do not assume every new deal requires a new feature.
4. What must be proprietary? Identify the specific business requirement that depends on owning the implementation, rather than simply preferring a familiar interface.
5. Could another team operate it? Ask for a handover using the documentation, retained inputs and test cases, without relying on one person's memory.

For selecting among suppliers after this architecture decision, use the separate royalty-software buyer's guide. This article does not rank vendors.

When building, buying or a hybrid is worth considering

Consider a build when you can show a consequential requirement that evaluated products cannot meet, explain why changing that requirement is unsuitable, and fund continuing ownership. Catalog size alone should not decide the question.

Consider a purchase when a demonstrated workflow meets the requirements and its commercial terms and operating responsibilities are acceptable. Treat a promised future feature separately from functionality demonstrated today.

A hybrid is also an option to evaluate—for example, a proposed internal reporting component alongside a purchased calculation system. This is an illustrative architecture, not a claim that any named supplier offers the interfaces it needs. Verify data access, permitted uses, integration support and responsibility for disagreements between systems. We do not claim that hybrids are common or uncommon in royalty accounting.

What to verify in a Qlero evaluation

Qlero's current documentation provides specific starting points for a demonstration:

• Terms and calculations: Contract terms describes condition-based sales, cost, deduction and escalation terms. Editing requires Agreements write access, and changing a shared term affects every contract using it. The calculation guide identifies Pro or Enterprise restrictions for participation overrides, deductions, escalations and PPD pricing.
• Imports: Custom-template setup describes mapping source columns. Custom templates require Pro or Enterprise, with appropriate template and sales-file permissions. This does not establish support for every provider format.
• Reporting finality: The period lifecycle separates publication and closing in Advanced mode; Simplified mode combines them. There is no Unpublish action, and a Closed period cannot be reopened or recalculated. These are specific workflow controls, not proof of a complete history of every user change.

Ask Qlero to demonstrate your agreement and file requirements, including recoupment where relevant. These guides do not establish that every bespoke arrangement, external integration or audit requirement is covered. A documentation gap is also not proof that a feature is unavailable.

Frequently asked questions

Is building always more expensive than buying?

No universal cost ranking is established here. Compare estimates and quotes for the same scope, workload and operating period, including the work your own team retains.

What is the biggest risk in building a royalty engine in-house?

There is no single risk ranking for every project. As a review priority, test whether ongoing ownership is funded and whether someone other than the original developer can explain and operate the system.

Is an in-house royalty system only an option for the largest labels?

Size alone is not a decision rule. Evaluate demonstrated requirements, capability and resources. This guide does not provide evidence about how many labels build their own systems or a transaction-volume threshold for doing so.

Can you switch from an in-house system to purchased software later?

Do not assume a future migration will be possible without further work. Evaluate export access, destination compatibility, agreement representation, opening balances and retention of historical outputs before committing. Ask the proposed destination team to demonstrate a representative transfer.

Can generic billing-software cost figures estimate a royalty engine?

Not without establishing comparable scope and evidence. A billing vendor's development figures are not a royalty-industry benchmark, and the label “royalty engine” does not by itself establish greater complexity or cost.

Does a hybrid approach ever make sense?

It is worth evaluating when a clear boundary lets one component meet a specific need. Confirm the interfaces and reconciliation responsibilities first. Separating components is not, by itself, evidence of lower cost or lower risk.

Choose who can support the whole lifecycle

The decision is not simply whether an engineer can reproduce today's royalty calculation. It is whether your chosen combination of people, software and suppliers can support the requirements you have actually tested.

Keep unresolved assumptions visible. Before committing engineering time or a software contract, book a Qlero demo with a masked source file, representative agreement terms and expected results. Use the demonstration to establish fit and limits—not as a substitute for your own acceptance decision.