From concept to 5M downloads, a consumer app built to become an enterprise data asset

Opensignal's existing consumer app was built for technical users, signal maps, cell tower data, network logs. It served a niche and wasn't growing. The company needed a new product that could reach a mass audience of non-technical users while simultaneously generating high-volume, high-quality data for Opensignal's B2B analytics products, the real revenue engine.

I pitched the concept for Meteor as part of my hiring process. Within weeks we were building it, and I stayed with the product from zero through launch and past it.

User interviews and competitive analysis surfaced a consistent problem: speed test results are meaningless to most people. Showing a user "47.3 Mbps" tells them nothing actionable. What they actually want to know is: can I stream Netflix? Will my video call drop?

Competitors competed on speed and feature depth. None of them had solved the communication problem underneath, and that was the opening.

Three strategic decisions shaped the product. I argued for them early and we held to them through development:

Bet 1, Results that mean something: Instead of raw Mbps numbers, grade your connection per activity, streaming, video calls, gaming, browsing. A Great/Good/Poor rating per use-case gives an immediate, actionable answer. That was a positioning call more than an interface one. It opened up a demographic that would never install a traditional speed test.

Bet 2, the shortest core loop we could get away with: open, tap, results. No account, no ads, no settings to configure. The one thing we could not remove was permissions, and nobody wants to hand those over to an app they just installed. So we built a short intro with Cosmo, a friendly monster character, who walked people through what the app does, what they get out of it, and why it needs the permissions it asks for. It worked far better than a permissions dialog on its own. Everything else we could take out, we took out.

Bet 3, Consumer app as B2B data asset: Reaching 5M non-technical users meant new geographic and demographic coverage for Opensignal's telecom dataset. This made Meteor strategically valuable to enterprise product even if it never became a direct revenue line.

Bet one only works if the grades are right. Behind the interface sits a configuration of apps and distinct activities, each with its own latency, download and upload thresholds, banded into grades. Streaming YouTube at 1080p is not the same threshold as sending a Snapchat, and a video call is not the same as loading a map. Somebody had to decide what “good enough” means for each one. Getting that wrong does not produce a slightly worse app, it produces one that confidently lies to people about their connection.

Retention as the north star: we agreed early, with our PM, to measure success on repeat usage rather than installs. That shaped prioritisation throughout: features that added depth without adding friction were in, features that complicated the core loop were out. The metric was thirty-day retention, and Meteor ended up with the highest of any Opensignal consumer app, on our own internal comparison rather than an industry benchmark. For scale: utilities and tools apps sit at roughly two to three percent at day 30, so a user who keeps coming back and keeps producing measurement data is a commercial outcome, not a vanity one.

Feature prioritisation post-launch: We ran post-launch iterations off user survey data and usage analytics. I led those, using dot-voting sessions with the team to cut scope and focus effort on the highest-impact changes.

Prototype-driven validation: I built a high-fidelity prototype before engineering started, then rebuilt it many times over. Each round went in front of real users, and what came back from those interviews changed the flow repeatedly before a line of production code was written. It worked well enough as a validation step that the team adopted it as standard practice for new products.