The feature we didn't ship
Two weeks before launch, our Slack channel lit up. A customer (let's call him Marcus) had asked a simple question: 'Can Attribr consolidate installs across multiple ad networks into a single dashboard view?' The answer was yes. We'd built it. We were planning to ship it in week one. Then we didn't.
The roll-up looked good on paper
In the months leading up to launch, we kept hearing the same request. Indie developers were tired of jumping between AppsFlyer, Adjust, and a handful of smaller networks just to understand where their installs came from. They wanted one view. One number. One truth.
So we built an ad-network roll-up. The logic was sound: pull install data from Facebook, Google, Apple, TikTok, and others; normalise it; surface a unified cohort view in our dashboard. It felt like table stakes. Every major attribution platform does it. Why wouldn't we?
Technically, it worked. Our small team had built something clean. But every time we looked at the roadmap, something didn't sit right.
The problem hiding in the feature list
Here's what we realised: we were trying to solve a problem that wasn't actually ours to solve.
Ad networks don't share install data willingly. They want lock-in. So to build a real roll-up, you end up doing one of three things. First, you ask developers to manually pipe credentials into your system and we become a permissions manager for every ad platform on earth. Second, you build deep API integrations with each network, which means maintaining relationships and contracts. Third, you go probabilistic and make educated guesses about which installs came from where, which is fine for some use cases but defeats the whole point of deterministic attribution.
We were falling into the second trap. And we'd only just launched Attribr.
The moment we stepped back, we saw clearly: that feature would own us. Every iOS update, every TikTok API change, every new ad network would require maintenance. We'd spend months fixing integrations instead of building what we actually do well.
What we chose to build instead
Instead, we made a different bet. We built something harder to copy and easier to maintain: a direct bridge to Rippl, our performance-marketing platform.
Rippl is where community members (we call them promoters) earn revenue by driving installs for indie games and apps. They're organised, they test creatives constantly, and they care about retention numbers because their earnings depend on it. For developers using Rippl, Attribr shows exactly which promoter drove each install and whether those users stuck around at day 7, 14, and 30.
This feature lives inside Attribr's dashboard. Three lines of code to integrate. No complicated permissioning. No maintenance nightmare. And it solves a real problem that nobody else was solving: giving indie developers visibility into community-driven acquisition.
It's narrower than a full ad-network roll-up. It's better for our specific customer. And it meant we could stay small and ship fast.
The constraint that shaped everything else
Saying no to the roll-up forced us to be honest about who we are. We're not building an enterprise attribution platform. We're not trying to be Adjust for everyone. Attribr is for indie developers and small studios who need to know three things: where did each install come from, are those users active at day 7/14/30, and if they came through Rippl, who drove the install.
That clarity changed every decision after. Our SDK is 50KB, zero third-party dependencies, sub-50ms launch overhead. It works on iOS 14.5 and beyond without needing ATT permission because we use both deterministic matching and probabilistic signals together. Three lines of Swift or Kotlin and you're live.
We didn't build what everyone wanted. We built what our customers actually needed.
What 'saying no' meant for launch
Launch week came. We shipped attribution, retention cohorts, funnel tracking, and that Rippl bridge. We didn't ship ad-network roll-up. We also didn't ship 90% of the feature suggestions that came in because they didn't fit the shape of the product.
Some customers were disappointed. That's the honest cost of building something specific instead of something generic. But the ones who stuck around - developers like Marcus - understood the trade-off. He got a lightweight SDK that didn't bloat his app, a dashboard that answered his real questions, and a CPI path through Rippl that actually worked.
Looking back, the constraint was the feature. By deciding what not to build, we figured out what to build well.
If you're an indie developer hunting for install attribution, does a tool that does one thing really well serve you better than a tool that tries to do everything?
Ready to try Attribr by MRVL?
One tap to download. No sign-up wall.