FieldGain

Offline-first engineering toolkit for field technicians to calculate, verify, troubleshoot, and document work on site.

Comment

Inspiration

I am not a software engineer by profession. I have spent approximately 18 years working in industrial automation, including active field work in a 1200 MW power plant.

In the field, calculations are not abstract exercises. A wrong value can mean wasted time, damaged equipment, or an unsafe decision. Connectivity is also not guaranteed: technicians often work inside electrical rooms, industrial facilities, concrete structures, or other areas where mobile data is unreliable.

I wanted an engineering tool that remained useful when the network disappeared and that I could trust for the same kinds of calculations I encounter in real work.

FieldGain grew from that need.

The project actually began somewhere very different. I had been building a multiplayer PvP mobile game with matchmaking, progression, achievements, and backend infrastructure. Instead of throwing everything away, I kept the strongest architectural pieces and rebuilt the product around a problem I understood much better.

The swords became sensors.

What it does

FieldGain is an offline-first mobile engineering platform for technicians and field professionals.

The current production release includes:

  • 105 engineering calculators
  • Electrical, automation, mechanical, HVAC, instrumentation, and industrial calculations
  • Offline-first formula access
  • Local calculation history
  • Premium cloud history and synchronization
  • PDF reporting
  • Configurable shortcuts
  • Rewarded usage paths
  • Character, Gear, and progression systems
  • Free and Premium product tiers

The calculation layer includes engineering formulas and reference-driven calculations such as PT100/RTD and thermocouple workflows.

FieldGain is designed so that meaningful engineering utility exists before the paywall. Premium extends the workflow rather than creating the entire product.

How I built it

FieldGain is built with Flutter, Firebase, Google Play Billing, AdMob, and RevenueCat.

AI has been an important development tool, but I did not treat it as an autonomous software engineer.

I built a decision-first engineering workflow around it.

Architectural decisions are documented before implementation, changes are audited, runtime behavior is verified, and accepted decisions are tracked through structured project documentation and Architecture Decision Records.

The principle became:

Decisions precede code.

That process became especially important as FieldGain grew beyond a calculator app into a system involving offline state, anonymous/pseudonymous accounts, cloud synchronization, subscriptions, rewarded ads, entitlement ownership, and recovery flows.

Monetization architecture

FieldGain does not rely on one static subscription screen.

Its monetization model follows multiple moments in the customer lifecycle:

Use → Engage → Reward → Convert → Recover → Protect → Measure → Retain

Free users receive meaningful utility and can use rewarded actions.

Rewarded-ad engagement on eligible placements can contribute to server-owned Loyalty. When a Loyalty milestone creates a conversion opportunity, RevenueCat resolves the provider-backed offer and FieldGain presents it inside the same Premium Shop.

The shop itself adapts.

Under normal conditions, monthly and yearly plans are shown, with the yearly plan receiving stronger value emphasis.

When a Loyalty or recovery offer is active, the same shop changes its visual hierarchy and makes the contextual offer the primary action.

FieldGain also includes an abandoned-checkout recovery path. After an explicit checkout cancellation, a bounded 24-hour recovery window can present a Standard or Boosted Premium opportunity depending on Loyalty state.

RevenueCat resolves the actual provider-backed subscription option rather than FieldGain inventing client-side pricing.

RevenueCat Ads measures rewarded-ad monetization alongside the subscription lifecycle, while Customer Center extends the lifecycle into subscription management after conversion.

The central monetization idea is:

One user. Multiple revenue moments. One monetization lifecycle.

The hardest monetization challenge: Premium ownership

One of the most difficult problems was separating a store subscription from the FieldGain account that should legitimately receive Premium access.

In field environments, devices and store accounts can be shared in ways that make a simple “the store says Premium, therefore this app account owns Premium” model insufficient.

I did not want to create a second billing system.

RevenueCat remains authoritative for provider subscription state.

FieldGain adds a server-authoritative canonical ownership layer that determines which FieldGain account currently owns the entitlement inside the application.

The normal path remains low-friction:

  • The same FieldGain account on another phone does not require a transfer.
  • The first legitimate transfer to another FieldGain account can complete immediately.

Rapid repeated transfers behave differently.

A repeated transfer enters a 72-hour Pending state. During that period, the existing canonical owner remains Premium and the target account remains pending.

After the cooldown expires, the target is only eligible — not automatically authorized.

FieldGain performs a fresh RevenueCat/provider check, and the user must explicitly complete the transfer before canonical ownership moves.

ELIGIBLE ≠ AUTHORIZED

This design intentionally protects subscription ownership without claiming to prevent every possible form of fraud.

Challenges I ran into

Offline-first engineering state

The product must remain useful when connectivity disappears while still supporting Premium cloud workflows when the network returns.

That required carefully separating local operation from cloud synchronization rather than treating the network as a permanent dependency.

Subscription state versus application ownership

RevenueCat can correctly report whether a provider subscription exists, but FieldGain also needs to determine which application account should currently own that entitlement.

Designing the 72-hour Revenue Protection flow without breaking legitimate restores required a separate server-authoritative state model.

Rewarded monetization without trusting the client

Rewarded usage needed to create value for Free users without making the client authoritative for rewards.

AdMob server-side verification and backend-owned reward/Loyalty state are used to keep that boundary on the server.

AI-assisted development at project scale

The challenge was not simply generating code.

It was preventing architectural drift as the project became larger.

That led to a workflow built around documented decisions, audits, verification, selective implementation, and explicit closeout rather than unrestricted prompt-to-code development.

Accomplishments I am proud of

The biggest accomplishment is that FieldGain is no longer only a development project.

It is now live on Google Play.

I built and shipped it while continuing my full-time work in industrial automation.

I am particularly proud that several systems that could easily have become separate experiments now work as one product:

  • 105 engineering calculators
  • Offline-first operation
  • Rewarded usage
  • Server-owned Loyalty
  • Adaptive Premium Shop
  • 24-hour checkout recovery
  • 72-hour Premium Revenue Protection
  • RevenueCat-backed subscription offers
  • RevenueCat Ads measurement
  • Customer Center
  • Premium Welcome Gift and progression systems

Rather than adding monetization after the product was complete, I designed it as part of the product lifecycle.

What I learned

The biggest lesson was:

AI does not replace software engineering decisions. It increases the importance of them.

AI helped me move faster, explore implementations, audit systems, and work far beyond what I could have produced alone in the same time.

But reliable software still required boundaries, evidence, testing, documentation, and the willingness to reject or rewrite generated work.

I also learned that monetization works better when it follows user context.

A paywall does not need to be one screen shown the same way every time. Engagement, checkout intent, subscription ownership, ads, and retention can become different parts of one coherent lifecycle.

What's next for FieldGain

The current calculator platform is the foundation, not the final boundary of the product.

The next product direction is:

Formula Wizards

Guided workflows for more complex engineering calculations, helping users move through formulas step by step.

Smart & Modular Checklists

Reusable field checklists that can connect procedures with calculations and verification instead of existing as isolated static forms.

Professional Knowledge Mini-Games

Short professional knowledge challenges that build on FieldGain's existing character, Gear, progression, and future competitive systems.

The longer-term direction is:

Calculate → Guide → Verify → Record → Progress → Compete

FieldGain started as a field calculation tool.

The goal is to grow it into a broader field platform — while keeping the product useful to Free users and allowing Premium to go further.

Built With

Share this project:

Updates

Submission history