We went looking for a Firebase alternative—and ended up building our own product. This is a practical account of how we evaluated options, why we considered “build vs. buy,” and what we learned while designing a lightweight deep-linking and routing layer that fit our needs.
Why We Looked Beyond Firebase
- Performance & routing control: We needed predictable link resolution with minimal redirects and strict path rules.
- Cost predictability: Usage patterns made variable pricing hard to forecast as campaigns scaled.
- Customization: We required opinionated behaviors around deferred deep linking, fallbacks, and parameter handling.
- Data ownership: Granular event capture, lean PII flows, and clear governance.
If you’re also moving on from Dynamic Links, start with a quick primer: Firebase Dynamic Links alternative.
What We Evaluated
We tested established suites and modern backends. Enterprise tools offered breadth and marketplaces; developer platforms offered flexibility. None matched our exact needs for routing depth, domain control, and a minimal ops footprint.
- Enterprise suites: great integrations and attribution, but heavier to implement and pricier at our stage.
- Backend platforms: powerful, yet required custom glue for Universal Links/App Links, fallbacks, and cross-channel QA.
Build vs. Buy: Our Decision Framework
| Criterion | Buy | Build |
|---|---|---|
| Time to value | Faster start, slower to customize | Slower start, tailored fit |
| Control over routing | Config-driven, sometimes rigid | Full control: paths, params, fallbacks |
| Cost profile | Licensing + integration | Eng time + hosting, lower overhead later |
| Lock-in risk | Higher (proprietary features) | Lower (portable rules & domains) |
| Compliance/data flow | Broad certifications | Design to principle of least data |
Our Requirements Checklist
- Verified domains for iOS Universal Links (AASA) and Android App Links (assetlinks.json).
- Zero or single redirect; canonical HTTPS; cache-friendly responses.
- Reliable post-install context to support deferred deep links.
- Deterministic routing rules (path → in-app destination) with safe fallbacks.
- Event hooks for analytics/BI without heavy PII handling.
What We Built Instead
A lean, backend-first linking layer: branded domains, strict path patterns, stable parameter capture, and cross-platform fallbacks. It supports deep links for existing users and restores campaign context after install for new users.
- Clean link domain: no unnecessary chains, predictable caching.
- Deferred context: preserves UTM/promo/referrer across the store step.
- Routing map: explicit path → screen rules, with desktop/private-mode fallbacks.
- Observability: click → open → in-app action, exportable to your stack.
What Changed for Us
- More predictable install-to-action flows thanks to stable routing and context restoration.
- Clear ownership of domains, headers, and association files (AASA/assetlinks).
- Simpler QA matrix for email, SMS, ads, social, and QR campaigns.
Lessons Learned
- Start from the QA matrix (installed vs. not, iOS vs. Android, webviews vs. browsers); design routing to pass those cases.
- Keep URLs stable and human-readable; minimize redirects to improve reliability.
- Treat fallbacks as first-class: desktop landing and “open in app” options matter.
Who Should Build vs. Buy?
If you need broad attribution and a partner marketplace, buying a suite can be the fastest route. If your priority is precise linking, domain control, and a small operational footprint, a focused, lightweight layer—or a custom build—often wins.
Conclusion
Our search for a Firebase replacement pushed us to build exactly what we needed: a tight, reliable linking layer that puts routing and context first. If you’re on a similar path, define your QA matrix, map requirements to build/buy trade-offs, and keep URLs—and ownership—simple.