The 50KB decision: why size and speed matter more than you think

What happens when your SDK isn't tiny

There's a hierarchy of needs when you're shipping an indie game or utility app. Performance comes high. Users don't care how much infrastructure sits behind the scenes; they care whether your app launches in a blink or a stutter. Every kilobyte of code you load at startup is a kilobyte that could have been spent on actual features.

Most attribution tools solve a real problem for enterprises with unlimited engineering budgets and user bases in the millions. They layer on multiple networks, heavy probabilistic fingerprinting, and integrations with dozens of ad partners. That weight made sense when you were buying attribution as part of a 300-person mobile ops team. It makes no sense when you're one person trying to ship a tight, responsive experience.

The moment I realised we needed Attribr differently was simple. We started building for indie developers, and the first thing they asked wasn't for fraud detection or advanced cohort analysis. It was: 'Will this slow down my app?'

The architecture choice that actually matters

Building a 50KB SDK with zero third-party dependencies wasn't a marketing decision. It was an architecture decision rooted in a single principle: do attribution detection with deterministic and probabilistic matching without asking your app to carry the weight.

Here's what that means in practice. When you integrate Attribr, you're adding fewer than 50 kilobytes to your bundle. No HTTP client library bundled in. No JSON parser included. No analytics framework piggybacking. The SDK talks to what your app already has. Launch overhead sits below 50 milliseconds on a real device, not a lab condition. That's the difference between imperceptible and measurable.

We made this choice because indie developers told us they use attribution data for one core reason: to answer three questions. Where did this install come from? Is the user still active in week one, two, or four? Did a Rippl promoter drive this CPI install? Everything else is noise on a limited engineering budget. By stripping away the feature bloat, we got to a version that answers those three questions with minimal footprint.

Why zero dependencies changes the equation

Zero third-party dependencies isn't a technical flex. It's a risk decision in your favour. Every external library you pull into your app is a potential security update you'll have to manage, a version conflict you might hit, and code you're trusting but not controlling.

For a small team, that overhead is real. One developer I spoke to spent a full day untangling a dependency conflict in a major attribution SDK, only to find the conflict existed because two internal libraries wanted incompatible versions of the same networking code. That kind of friction multiplies when you're moving fast.

By building Attribr without external dependencies, we made a bet: that what indie developers actually need is simpler than what enterprise tools provide. Install source attribution works fine with deterministic matching (did the user click an ad link we can trace?) plus probabilistic matching (did the timing, device, and user behaviour patterns match a known campaign?). You don't need a heavy machine learning stack running on your phone. You need the signal that matters.

What you actually get with three lines of code

I want to be specific about what Attribr does, because the simplicity is real but the functionality isn't trivial. You integrate it in Swift or Kotlin in roughly three lines. From that moment, you're tracking: install source (which network, which campaign, which partner drove the user); retention cohorts at day 7, 14, and 30; and if the install came through Rippl, which promoter was behind it.

The integration doesn't require ATT permission on iOS 14.5 and up. The SDK works without asking users whether you can track their activity. That matters for indie developers operating in a post-privacy-label world where asking for permission visibly costs you installs.

The dashboard shows retention over time, funnel drop-off, and cohort performance. It's not a replacement for deeper analytics, but it answers the specific question every indie developer asks: 'Is my growth sustainable?' If users are installing but churning at day three, you see it. If a particular campaign is driving higher-quality installs, the seven and fourteen day cohorts tell you.

The Rippl connection changes the game for a specific kind of developer

Here's where Attribr does something no other indie-focused attribution tool does. If you're using Rippl for performance marketing, Attribr has a direct bridge into that network. You don't just see that an install came from 'organic' or 'paid'. You see which Rippl promoter drove the CPI install. That's a feedback loop that matters for community-driven growth.

It's a small feature on paper. In practice, for developers using Rippl, it closes a gap that frustrated them for months. They could see their CPI on the Rippl side, but couldn't connect it back to retention in their own data. Now they can. That alignment is worth more than a dozen abstract features.

What matters when you're building lean

I've been thinking about attribution wrong for years. Enterprise tools measure success in breadth of features and integration partners. Indie tools should measure success in clarity per kilobyte. How much decision-making capability can you get per unit of bundle size? How much launch time overhead are you willing to trade for a specific signal?

For most indie developers, the answer is: almost none. A 200ms launch delay isn't acceptable. A bloated SDK with ten times more features than you need isn't acceptable. Attribution should answer your actual questions without inflicting costs on your users.

That's what 50KB and sub-50ms overhead really means. It means we've made architecture choices based on what indie developers actually need, not on what's technically impressive or enterprise-approved. It means the integration takes three lines because we've thought hard about how to get signal without complexity.