When a Side Project Becomes the Tool You Actually Need: Building for Cloudflare on Mobile

I was sitting in Jawa café in Islamabad last month, waiting for a deploy to finish, when my phone buzzed with a DNS propagation alert. I reached for my laptop instinctively—then stopped. Why was I carrying a 15-inch MacBook to a coffee shop just to toggle a firewall rule or check if my cache had purged properly? That's when I stumbled across a React Native app that someone built to manage their entire Cloudflare account from a phone. It got me thinking about something I've been wrestling with for years: not all tools need to be web-first.

The project is simple on the surface but ambitious in scope—a full-featured Cloudflare management application built with React Native and Expo that lets you handle DNS records, Workers, R2 buckets, firewall rules, and more without opening a browser. It's unofficial, it's open-source, and it's exactly the kind of pragmatic tooling that shouldn't exist but desperately needs to.

Why This Actually Matters More Than You'd Think

Here's what struck me: Cloudflare's dashboard is already excellent. It's responsive, it's fast, it's feature-complete. So why would someone spend weeks building a mobile-first replica? Because the web isn't always the right interface for every interaction.

When you're managing infrastructure from a phone, you're usually in one of two situations: something is actively broken and you need to fix it in 30 seconds, or you're checking status asynchronously between other tasks. The mobile web experience, even for a well-designed dashboard, adds friction. You're dealing with touch targets designed for desktop cursors, viewport issues, and the cognitive load of rendering a full interface on a 6-inch screen.

A native mobile app solves this differently. The developer here built shortcuts that matter: one-tap security level toggles, quick actions carousels, a real-time Worker log tail that actually fits on a phone. You're not navigating a dashboard—you're performing discrete, high-priority operations.

The Technical Decisions I'd Respect in Production

Let me break down what makes this architecture sensible. The stack is React Native with Expo, which means one codebase compiles to both iOS and Android without duplicating business logic. That's pragmatic for a solo developer. They're using Expo Router for navigation instead of rolling custom routing—a decision that probably saved 40+ hours of debugging.

The credential storage piece deserves genuine respect. API tokens are stored in Android Keystore, which is hardware-backed encryption. They're not persisting sensitive data to plain shared preferences or some cloud backend. That's the security posture you want from even unofficial tooling handling your account credentials.

The architecture hits the API directly (axios to Cloudflare's v4 API), which means no proxy server, no analytics collection, no hidden middleman. For an unofficial app especially, this transparency matters. You control what you send to Cloudflare—period.

Where I'd Push Back a Bit

Here's my honest critique: the feature surface area is massive. DNS records, Workers, KV, R2, Pages, firewall rules, analytics, audit logs, biometric lock, email routing, page rules, multi-account switching, localization in two languages. That's not a minimum viable product—that's enterprise-grade feature parity.

I'd ship 40% of this initially. DNS management and zone status would be enough. Workers tail logs and KV namespace browsing are luxuries that could come in version 2. The more features you have, the more surface area for bugs, the harder it is to maintain security.

Also, I notice the app requires fairly permissive API token scopes to function. You're asking users to give read/edit access across zones, DNS, firewall, workers, and analytics. That's sensible for a tool that needs broad capabilities, but it means users have to really trust your code. It's not the fault of this developer—it's just the reality of building comprehensive infrastructure tools.

What This Teaches About Platform Choice

Building this in React Native was the right call, but it made me think about when to choose React Native versus pure native. The developer clearly needed rapid iteration and cross-platform compatibility more than pixel-perfect performance. Expo accelerates that dramatically. You're not wrestling with Xcode or managing native dependencies across two platforms.

If you need features like deep integration with OS-level networking stacks or hardware-specific APIs, pure native is still your answer. But for a feature-rich HTTP client that calls Cloudflare's REST API and renders tabular data? React Native eliminates complexity without sacrificing functionality.

The Real Question

What makes me respect this project isn't technical cleverness—it's recognizing a legitimate gap. Cloudflare doesn't ship an official mobile app because the ROI doesn't justify it for their business. But developers who live in their infrastructure genuinely benefit from this tool existing. That's a market signal worth paying attention to.

I'm now thinking about what infrastructure tools I use daily that would be genuinely better as native mobile apps. Kubernetes dashboard for cluster troubleshooting? Database query runner? Log tailing? The more I think about it, the more I realize we've defaulted to "mobile web" when "native mobile" might actually be better for specific problem domains.

Source: This post was inspired by "CloudFlare Mobile - A full-featured Cloudflare management app built with React Native & Expo" by Dev.to. Read the original article