The case for building alone: why Attribr has zero third-party dependencies

The dependency trap

When we started building Attribr, we did what most teams do. We grabbed existing libraries for JSON parsing, time handling, networking. It felt sensible. Industry standard. Proven code. Within a few months, we had four major dependencies and several smaller ones.

Then I got an email. One of those libraries had a breaking change. Our SDK was pulling in a version that would no longer work with a specific iOS configuration. We could update, but that risked introducing new bugs. We could pin the version, but we'd be stuck on legacy code. Neither option was clean.

That's when it hit me. We weren't building an attribution system; we were building a dependency tree that happened to do attribution. Every external library we used was another potential point of failure, another maintainer's roadmap we had to follow, another security audit surface area. For an indie developer trying to understand their install sources, we were introducing friction they didn't ask for.

The brutal truth: third-party code is someone else's bet on what the future looks like. If their bets change, your app changes with it.

What 'zero dependencies' actually means

We didn't decide this on ideology. We did it because our core problem is narrow and solvable. Attribr needs to do three things: collect data, match installs to sources, and send results to our dashboard. None of that requires pulling in someone else's HTTP library or JSON encoder.

So we wrote them. All of it. HTTP layer, JSON parsing, cohort calculations, time utilities, crypto for deterministic matching. The result is 50KB of code that you can read, audit, and understand. No black boxes. No surprise transitive dependencies.

We also kept our launch overhead below 50ms. Every dependency we didn't include is latency we didn't add to your app's startup. That matters more than most developers think. A hundred milliseconds on launch is the difference between a smooth first experience and a noticeable hitch.

What we didn't do is reinvent the wheel where it's already been solved by the platform itself. We use native iOS and Android APIs wherever they exist. We just don't wrap them in unnecessary layers.

The maintenance argument nobody makes

Here's the part people don't talk about: maintenance gets harder with dependencies, not easier. Every external library needs updates. Security patches. iOS version compatibility fixes. If you're tracking even five dependencies across two platforms, you're running a constant upgrade treadmill.

We don't have that problem. Our code only needs to work on iOS 14.5+ and Android 5.0+. We own the entire stack. When Apple releases a new iOS version, we test Attribr against it. We don't wait for a dependency maintainer to release a compatible version. We don't file issues hoping for a fix.

For an indie studio with two people handling app development, this is the difference between shipping features and fighting build configurations. Every hour we don't spend managing dependencies is an hour we spend improving retention tracking or adding new dashboards.

It's also why our Pro customers can bring their own ad networks. We're not locked into a specific dependency's integration framework. We built the bridge infrastructure from scratch, which means it can adapt to however you want to integrate.

The security case that's quietly important

I've never seen an indie developer sit down and audit every transitive dependency their app pulls in. Not because they don't care, but because it's impossible. An HTTP library might use a JSON parser that uses a utilities library that does something else. By the time you count all the code running inside your app, you have no idea what you're actually shipping.

With Attribr, there are no hidden layers. We handle everything. We own the surface area. If someone finds a vulnerability in our code, we patch it immediately. No waiting for a third-party maintainer. No negotiation about whether it's in scope for them to fix.

That matters more for attribution than it might for other SDKs. We're collecting information about your users' install sources, devices, and retention. That's sensitive data. The fewer hands in the pipeline, the fewer points where something can go wrong.

What this trade-off costs

We're not blind to the argument against this approach. Building everything yourself means more code to maintain. More testing. More risk of reinventing something that's been solved a thousand times before.

We pay that cost. Happily. Because the upside is clarity, control, and speed. Our SDK works. It stays lean. It doesn't surprise you with transitive updates or compatibility nightmares. When we say it weighs 50KB and launches in under 50ms, we're not hedging around dependency versions or runtime configurations.

The trade-off only works because our scope is intentionally tight. We're not building a payments SDK or a video streaming library. We're solving attribution. That's specific enough to own completely.

Why this matters for your app

You probably don't think about SDK dependencies much until something breaks. Then it consumes every second of your week. You're chasing version compatibility. You're reading GitHub issues from people with different problems. You're hoping someone maintains the code you're relying on.

Attribr exists in a different category. We're built to last. Not because we're a massive enterprise team with deep resources, but because we deliberately made ourselves maintainable. No external dependencies means no upgrade treadmill. No surprise compatibility issues. No hoping for a fix from someone else.

For indie developers and small studios, that's worth something real. It's the difference between an SDK that works consistently, month after month, and one that demands attention every time iOS or Android changes.