Build vs. Buy: The Real Cost of an In-House iGaming Affiliate Tracking Stack

Most build-vs-buy content frames this as a philosophy question — control versus convenience, ownership versus speed. It isn’t. It’s a costing exercise, and most new operators skip it because nobody on the founding team has priced affiliate tracking infrastructure before.

The instinct is understandable. You already have engineers. Postback logic sounds like a weekend project until someone opens the spec for NGR-aware commission calculation with negative carryover, and the weekend project becomes a permanent maintenance obligation nobody budgeted for.

We, the team behind Scaleo, have watched this pattern from both sides — operators who built and later migrated to us, and operators who priced the build honestly before writing a line of code and never started. The difference between the two groups usually comes down to one thing: whether anyone scoped the actual components before estimating the timeline.

This is that scoping exercise. What it actually costs to build iGaming affiliate tracking in-house, what SaaS actually costs by comparison, and where the break-even point genuinely sits — not the marketing version of any of those numbers.

What Does “Building” Actually Mean?

“Building in-house” is not one project. It’s six, and most cost estimates fail because they get priced as one.

A functioning iGaming affiliate tracking stack requires: a click ID and attribution capture system that survives redirect chains and app-to-web handoffs; a server-to-server (S2S) postback endpoint that multiple affiliate networks and traffic sources can hit reliably; a commission calculation engine that handles NGR and GGR logic, negative carryover, and hybrid CPA+RevShare structures without silent rounding errors; fraud and anti-abuse logic that catches self-referral, VPN-masked click farms, and cookie-stuffing before commissions accrue; an affiliate-facing reporting dashboard accurate enough that partners stop emailing to ask why the numbers don’t match; and payout reconciliation that handles multi-currency, multi-provider payment rails without a spreadsheet quietly holding the whole thing together.

Skip any one of these and the build isn’t smaller. It’s incomplete.

Most first-time in-house builds ship five of the six. The one that gets deprioritized is almost always fraud logic, because it doesn’t block launch and nobody feels the cost until the first bad weekend. We’ve watched that exact sequence play out across enough early-stage operators that we no longer ask whether fraud detection is in scope for the first release. We ask when it’s getting added back in.

What Does It Actually Cost to Build In-House?

Cost has two components operators consistently underprice: the initial build, and the maintenance load that starts the day it ships and never stops.

Ongoing maintenance is where most build estimates quietly fall apart. Keeping pace with provider parameter changes, evolving fraud patterns, and jurisdictional compliance updates typically runs 25–35% of the original build effort every year — roughly 400–950 hours annually, or $48,000–$152,000 a year at the same blended rate. That’s not a one-time cost. That’s every year the system stays in production.

Every hour an engineer spends debugging a postback edge case from a traffic source that changed its parameter format without notice is an hour not spent on whatever the operator’s actual product is. For an iGaming operator, that product is the platform, the game catalog, the player experience — not the affiliate backend. Affiliate tracking is infrastructure. Infrastructure that doesn’t differentiate the business shouldn’t consume differentiation-stage engineering time.

What Does It Actually Cost to Buy SaaS?

SaaS affiliate tracking for iGaming operators is priced in tiers, not as a single number, and the tier breakdown is covered in full detail in iGaming Affiliate Software Pricing: What Operators Actually Pay in 2026 — worth reading in full rather than re-derived here. In broad terms: entry-tier platforms for single-brand operators typically run $500–$900 per month, mid-tier platforms with multi-brand support and native fraud detection run $1,200–$2,000 per month, and enterprise tiers built for high-volume, multi-brand operations run $2,500–$5,000+ per month.

Implementation is measured in weeks. A from-scratch build needs four to nine months to reach production parity across all six components above — and that’s before the first bad weekend teaches the team what was missing from scope.

The 3-Year Total Cost of Ownership

Run both paths through a three-year model, using a $310,000 initial build, $90,000 annual maintenance after year one and a $1,500 monthly SaaS subscription, and the picture stops being close.

The gap between these numbers isn’t a rounding error, and it isn’t close enough to justify hedging. Over three years, building in-house costs roughly nine times what buying does — before accounting for the fact that the year-one build figure assumes the estimate holds, and first builds almost never hit their own hour estimates.

When Building Is Actually the Right Call

Building is occasionally correct. Not often, and not for the reasons operators usually give.

Genuinely unusual NGR or deduction logic. A small number of operators run commission structures — jurisdiction-specific deduction stacking, bonus-abuse-adjusted NGR, or hybrid models layered three deep — that no SaaS platform we’ve evaluated models correctly out of the box. If that’s the actual situation, not a perceived one, building the calculation engine specifically may be justified. Everything else on the list above still shouldn’t be built from scratch.

Idle engineering capacity that would otherwise sit unused. If a team has committed, funded engineering headcount with no other roadmap claim on their time for the next two quarters, the opportunity cost calculation changes. This is rare. Most early-stage operators don’t have idle engineers — they have engineers who are already behind on the core product.

Data-residency constraints that rule out third-party hosting. A small number of jurisdictions impose hosting requirements that some SaaS vendors can’t satisfy. Confirm this against the specific vendor’s infrastructure before assuming it applies — many platforms, Scaleo included, support region-specific hosting configurations. Don’t build around a constraint that a vendor conversation would resolve in a week.

The Hidden Costs Operators Underestimate

The number that kills most build decisions isn’t the build cost. It’s the cost nobody put in the spreadsheet.

Key-person risk. Affiliate tracking systems built by one or two engineers tend to stay understood by one or two engineers. When either leaves, the operator doesn’t just lose a team member — it loses the only documentation that mattered, in someone’s head. This exact failure mode is covered in more depth in Switching From Custom-Built to SaaS Affiliate Platforms, under what we call the knowledge concentration problem.

Feature-velocity gap. A SaaS platform with continuous dedicated development ships fraud pattern updates, new provider integrations, and compliance changes on a schedule the vendor owns. An in-house system ships updates when the one engineer who understands it has time — which, in practice, means after the core product roadmap, not before it.

Compliance-update lag. Reporting requirements and audit-trail standards shift by jurisdiction and by regulator, often with short notice. A platform vendor amortizes that update cost across every operator on the platform. An in-house build amortizes it across exactly one operator: you.

A Quick Decision Checklist

This isn’t a scored rubric — that’s a different post, and a different asset. This is a gut check. Answer honestly before pricing anything else.

• Do we have engineering capacity that would otherwise sit idle for the next 6–12 months?
• Does our commission logic involve NGR or deduction rules unusual enough that we’ve already confirmed, not assumed, no SaaS platform models them correctly?
• Are we operating under a data-residency requirement we’ve confirmed — not guessed — rules out third-party hosting?
• Can we commit to permanent engineering ownership of this system, not a project sprint that quietly becomes permanent?
• Have we priced fraud detection, postback reliability, and payout reconciliation as separate line items — not folded into “the tracking system”?
• Would losing the one or two engineers who understand this system put affiliate payouts at risk?
• Is our core product differentiated enough that engineering hours are better spent there than on infrastructure a vendor already built?

Use the answers to price both options against the same requirements. The questions reveal exceptions to test, not a score that decides the purchase for you.

Once you’ve decided to buy, the next question is which platform — that comparison lives in The iGaming Affiliate Software Decision Matrix. And if you’re earlier than this decision, still mapping out what the first 90 days of an affiliate program actually look like, The Five Stages of an iGaming Affiliate Program covers that ground.