---
title: "Latitude Longitude Finder"
description: "It started as one screen showing the phone's current coordinates. Nine major versions later it has an in-app map, place search, geocoding, a coordinate converter and field tools, 300k+ organic installs and recurring subscription revenue. Every step was driven by user feedback and measured with Firebase A/B tests on features, paywalls and the store listing itself."
url: "https://dewmina.dev/projects/latitude-longitude-finder"
canonical: "https://dewmina.dev/projects/latitude-longitude-finder"
kind: "PRODUCTION"
year: "2020"
status: "Live on Google Play and the App Store · v9.8"
role: "Founder and sole engineer: product, growth, experiments and nine major versions since 2020"
author: "Dewmina Udayashan"
---

# Latitude Longitude Finder

A coordinate readout grown into a 300k+ install utility with recurring revenue.

It started as one screen showing the phone's current coordinates. Nine major versions later it has an in-app map, place search, geocoding, a coordinate converter and field tools, 300k+ organic installs and recurring subscription revenue. Every step was driven by user feedback and measured with Firebase A/B tests on features, paywalls and the store listing itself.

**My role:** Founder and sole engineer: product, growth, experiments and nine major versions since 2020

**Status:** Live on Google Play and the App Store · v9.8

**Links:** [App Store](https://apps.apple.com/lk/app/latitude-longitude-finder/id6758548238) · [Google Play](https://play.google.com/store/apps/details?id=com.dewdev.lat_long_finder_full_final)

**Stack:** Flutter, Dart, Google Maps, Google Cloud, RevenueCat, Google AdMob, Google Places, Firebase, Remote Config, A/B testing, Codemagic, Shorebird, ASO

## By the numbers

- **300k+** Organic installs, zero paid acquisition
- **9** Major versions shipped since 2020
- **18** Remote Config parameters behind experiments and gates
- **2** Platforms from one Flutter codebase

## The problem

Retrieving a precise coordinate sounds trivial until the network drops, the user needs MGRS instead of decimal degrees, or the device reports an accuracy figure nobody surfaces. The harder problem was commercial: an app with no marketing budget only grows if the store listing does the acquisition and the monetisation converts the traffic it brings, and with a large installed base every change to onboarding, pricing or placement is a bet on real revenue. That makes ASO, paywall design and feature gating engineering problems with a measurement loop, not a marketing afterthought.

## The approach

- **Offline retrieval.** Cached mapping and a location pipeline that keeps producing a usable fix and a readable coordinate with no active data connection.
- **The whole picture of a place.** Address, coordinates in multiple formats, altitude, compass bearing and share-ready export, so the app answers the next question as well as the first one.
- **Growth as a measured loop.** Onboarding flows, paywall layouts, default plans and feature gates are Remote Config parameters, tested against each other with Firebase A/B Testing on a written funnel. Store listings are tested the same way.
- **Built from what users asked for.** The map, place search, geocoding, the converter and the field tools each arrived because reviews and feedback asked for them, one release at a time across nine major versions and a later iOS launch.

## System architecture

- **Sensing.** Location service streams with accuracy reporting, magnetometer compass and altitude
- **Coordinate core.** Decimal degrees, DMS, UTM and MGRS with smart detection on input
- **Mapping & places.** In-app Google Map with selectable styles and cached tiles, Google Places autocomplete search, forward and reverse geocoding
- **Monetisation.** RevenueCat subscriptions behind a remotely versioned paywall, AdMob with Meta and AppLovin mediation, and rewarded ads that unlock a gated tool for three days
- **Experimentation.** 18 Remote Config parameters driving Firebase A/B tests and feature gates, resolved before the first frame so first-launch surfaces can be tested
- **Measurement.** A documented Firebase Analytics event dictionary with user-scoped variant properties, Crashlytics and Performance Monitoring
- **Release.** Tag-driven Codemagic pipeline, changelog-generated store notes, and Shorebird for Dart-only patches

## Engineering decisions

### Treating the store listing as part of the product

With no ad budget, the listing *is* the acquisition channel. Title, subtitle, screenshot order and keyword set were iterated against install and conversion data, and the listing itself was A/B tested the way a feature would be. That is how an app reaches six figures of installs on organic search alone.

### Subscription and ads, not one or the other

Most of the audience will never pay and still has value; a minority wants the app clean and will. RevenueCat subscriptions sit alongside AdMob mediation, with the paywall as the removal path and rewarded ads as a middle road: watch one, and a gated tool unlocks for three days. Which tools offer that is a Remote Config switch, so the balance between ad revenue and subscription pressure is tuned without a release.

### An experiment is only as honest as its exposure

Onboarding can only be tested if the variant is known before onboarding renders, so Remote Config is awaited before the first frame. The test targets first opens only, because the installed base never sees onboarding and would dilute any real difference toward zero. The paywall keys that move the same funnel are frozen for the run, and trial starts are guarded by trial-to-paid, because an onboarding that wins on trials and loses on revenue is buying cancellations.

### Crash data decides the next release

Crashlytics clusters are read before the roadmap is. One release was cut mainly to close a single cluster: a null from the native ads SDK crossing into a non-nullable Dart field on every failed ad load, which was the largest source of crashes in the previous version. The fix and its root cause went into the changelog that becomes the store notes.

## From one screen to a business

The first version did one thing: it showed the phone's current latitude and longitude. Everything else on this page came afterwards, one release at a time, in the order users asked for it.

AdMob came first, so the app could pay for itself. Then an in-app Google Map, because a coordinate means more when you can see where it is. Then Google Places autocomplete, so people could search for somewhere rather than stand in it, and forward and reverse geocoding, so an address could become a coordinate and a coordinate an address. The converter, compass, measurement tools and map styles followed the same way: a request in the reviews, a feature in the next version.

Then in-app subscriptions, through RevenueCat. That turned a utility with ad income into a product with recurring revenue, and it has produced monthly recurring revenue consistently since. Nine major versions later it has more than 300,000 installs, none of them paid for.

## Every change is an experiment

With an installed base that size, a change to onboarding or pricing is a bet on real money, so it is not made on instinct. The levers are Remote Config parameters: which onboarding flow a new user sees, which paywall layout and default plan they land on, whether the paywall can be dismissed, which tools can be unlocked by a rewarded ad, and when the app is allowed to ask for a review. Firebase A/B Testing assigns the variants, and the app emits a documented event dictionary that names every event, its parameters and the custom dimensions it has to be registered under, so a result can be read by funnel step rather than as one number.

The experiments are written down before they run. The onboarding test, for instance, states its question, its primary metric, its guardrail, the parameters frozen for its duration, a sample-size table and the pitfalls specific to this app. The store listing is tested the same way: its graphics and copy are variants with a metric, not a matter of taste.

Review prompts get the same treatment. The app asks only after a user has completed a set number of successful actions, so a brand-new user is never asked, and never again within a cooldown window, and every one of those thresholds is remote so they can be tuned without shipping.

## Owning what happens after release

Crashlytics and Performance Monitoring are how releases are judged, and the crash clusters set the next release's priorities. Releases themselves are tag-driven: a version tag on a release branch builds both platforms through Codemagic with Shorebird, and pulls the release notes from the changelog, so the store copy is written when the change is made rather than reconstructed afterwards.

---

Written by Dewmina Udayashan. Full site: https://dewmina.dev