From Code to Google Play: Shipping MicroQuote as a Solo Developer

Earlier this month, production release versionCode 8 of MicroQuote went live on the Google Play Store .

The part that actually surprised me wasn’t the TypeScript, the SQLite schema, or the PDF layout. It was that finding 12 people willing to install an unfinished app and actually use it for two straight weeks turned out to be harder than writing the offline sync logic.

The Problem: Quoting Software Wasn’t Built for the Job Site

Most software built for small business quoting assumes an idealized environment: high-speed fiber, a desktop monitor, and enough time to sit down with accounting software.

That’s not the environment independent tradespeople work in — plumbers, electricians, carpenters, mechanics, site contractors. Standing in someone’s driveway or inspecting a distribution board in a basement looks like this:

Your hands are dirty.
Cellular signal is often intermittent or completely absent.
You don’t have time to log in to a web dashboard or click through a multi-step form.
If you don’t quote right there, you have to remember to do it hours later — and every hour of delay drops your conversion rate.

I wanted a focused, fast utility that does one job well: let an artisan enter line items, calculate totals, capture a client’s signature on glass, and generate a branded PDF quote ready to send over WhatsApp before leaving the driveway.

Architecture Decisions for an Offline-First React Native App

When you’re the only engineer, the only tester, and the only support line, architecture is risk management. The clearest example of what that meant in practice: I never built a backend for MicroQuote. No auth service, no API, no database to operate. A cloud backend would have meant something new to monitor, patch, and pay for — and I’m the only person who’d get paged when it broke. So the app doesn’t have one.

Offline-First as a First-Class Requirement (Expo SQLite)

In South Africa and many emerging markets, relying on a cloud backend for basic operations is a non-starter on an active job site. MicroQuote had to work with zero connectivity, so persistence is local: expo-sqlite and local storage handle quotes, line items, customer records, and settings, reading and writing at local latency with no server roundtrip to wait on. There’s a second benefit that only matters when you’re building alone — there’s no sync layer to reconcile, which means there’s no 2am sync-conflict bug for a team of one to debug.

On-Device PDF Generation and Signature Capture

Sending payload data to a cloud rendering service would add latency, a privacy question, and a server bill. Instead, document generation happens entirely on-device: HTML/CSS templates render dynamically and compile to PDF via expo-print. Signatures are captured on a touch canvas and embedded as base64 vector paths directly into the PDF layout. The finished document goes straight to expo-sharing, so the tradesperson can send it over WhatsApp, email, or Bluetooth in seconds. As with the backend decision, the real payoff is that there’s no rendering service for me to keep running — nothing else in this app can go down at midnight because I forgot to renew a certificate.

Lightweight, Zero-Dependency Internationalization

MicroQuote ships in six languages out of the box: English, Afrikaans, Spanish, French, German, and Portuguese. Rather than pull in a heavyweight localization library with dozens of transitive dependencies, I wrote a small catalog resolver on top of expo-localization — it detects device locale, resolves keys against type-safe JSON catalogs, and handles string interpolation directly. Six language catalogs are already a lot of surface area for one person to keep consistent; I didn’t want to also be the one tracking breaking changes in someone else’s i18n package.

Hardening and Performance

Android build properties are configured with R8 and Proguard to strip unused bytecode and shrink resources, which keeps the download small on budget hardware — the kind of device most of MicroQuote’s actual users carry. Lightweight telemetry through EAS Observe tracks time-to-interactive and real-world performance across low-end and flagship devices, because I don’t own a device lab and can’t personally test every screen size and Android version this app runs on; the telemetry is the only way to know it actually works on hardware that isn’t mine.

Billing runs through RevenueCat rather than anything I built myself — a subscription and entitlement system is exactly the kind of infrastructure I didn’t want to be the one operating and debugging alone, especially anything touching payments. The free tier caps out at 5 quotes a month with a watermark on the PDF; that limit wasn’t modeled off usage data, it was a number I could defend if anyone asked, and a natural point where someone still trying the app out would run into it. Pro removes the watermark and the cap. I didn’t build tiered pricing beyond that single split — one more thing to design, test, and support alone that a plain free/paid line doesn’t need.

Navigating Google Play’s Closed Testing Requirements as a Solo Developer

Google now requires at least 12 opted-in testers using the app for a minimum of 14 days before it can go to production. On a team, that’s a QA rotation. Solo, it means personally recruiting 12 strangers or acquaintances willing to install an unfinished app and stick with it for two weeks — no existing beta community, no marketing team to pull from. This was the step that took longer than any single piece of the codebase.

The data safety audit was its own kind of work: proving zero unnecessary data collection, documenting local storage encryption, and scoping every Android permission down to what the app actually uses. There’s no privacy team to sign off on this — I read the Play data safety form line by line and matched each claim back to the actual code that made it true.

Then came verification across screen densities, OS versions, and notch layouts — tested on whatever hardware and emulators I had access to, until versionCode 8 cleared review.

It cleared on a weekday morning. I checked that the download link actually worked from my own phone, and went back to what I’d been doing before the notification came in.

Key Takeaways for Solo Engineers Shipping Their First App

Scope to what you can finish alone. There’s no PM to push back when the feature list grows and no second engineer to split the work with, so MicroQuote does one job — quote, sign, send — and nothing else. Every feature not on that list is a feature only I would ever maintain.
Offline-first cuts your own support load, not just the user’s friction. A network-dependent bug — “it says connecting and never finishes” — is a debugging session with no one to triage it with you. Removing the network removed an entire category of tickets I’d otherwise be reading alone.
You’re the only code reviewer, so keep the dependency tree small. On a team, a risky new library gets a second pair of eyes before it ships; solo, whatever you npm install goes straight to production. That’s the actual reason MicroQuote’s i18n layer is a hand-written resolver instead of a package — I didn’t want to be the sole auditor of someone else’s dependency across six languages.
Use an externally imposed deadline when you get one. With no team sprint cadence and no launch date set by anyone but me, it’s easy to keep polishing indefinitely. The 14-day closed testing clock was the only deadline I had, so I built the release around it instead of around “done.”

MicroQuote is developed by Lagari Group and is available now on the Google Play Store .