Key takeaways: The expensive parts of this build were not the screens. Reference data, offline infrastructure, and verification ate most of the effort. Cost ranges without line items don't tell you much; the useful question is which line items your app has. Deferring the backend until usage justified it was our biggest single cost control. And the app is on both stores, so you can check all of this yourself.
Every Cost Guide Gives You the Same Table
Search "react native app development cost" and you get the same article over and over: simple app $15k–$40k, medium $40k–$120k, complex $120k–$250k, followed by "it depends." Nobody shows you a real app with the dependency actually worked out.
So here's one. This post goes through an app we designed, built, and shipped ourselves, line by line. You don't have to take our word for any of it, because [FieldDojo is on the App Store](https://apps.apple.com/app/fielddojo-trade-calculators/id6761429113) and [Google Play](https://play.google.com/store/apps/details?id=com.notchip.calcrig) right now.
The App Being Torn Down
FieldDojo is a field calculator for the trades: 57 calculators across electrical, HVAC, plumbing, and construction, each one showing the formula it used and the code section it's based on (NEC, ASHRAE, UPC, IRC), adapted to six regional code sets. It's offline-first because job sites rarely have signal, free with a Pro subscription on top, and built with React Native 0.86 on Expo SDK 57. There's already an engineering walkthrough and a case study if you want the how. This post is about where the effort went.
First commit was 2026-03-24. App Store approval of version 1.0.0 came just under 16 weeks and 280 commits later, and the Play Store release followed inside the month.
The Line Items
| Line item | What it involved | Weight |
|---|---|---|
| Reference data entry and verification | NEC/ASHRAE/UPC/IRC tables transcribed into structured data, checked against worked examples, multiplied across six regional code sets | The heaviest line — see below |
| Offline-first data layer | op-sqlite + Drizzle, versioned migrations, a sync queue with a conflict policy | Heavy |
| 57 calculation engines | Pure TypeScript functions with typed inputs, outputs, formulas, and code references | Moderate — marginal cost fell fast once the pattern existed |
| UI and design system | Tab navigation, the CalculatorSection component, one shared numeric-input hook | Moderate |
| Store submission and device QA | Two store submissions, physical-device passes for keyboard behavior | Small but non-skippable |
| Backend, auth, and billing | Hono + Postgres + Better-Auth, cloud sync, subscriptions | Deferred entirely to a second phase |
| Maintenance | SDK upgrades, OS releases, store policy changes | An annuity, not a line item |
Two rows tend to surprise people: the top one and the deferred one.
Why the Boring Parts Dominate
UI cost scales with the number of screens. Data cost scales with how correct the data has to be, and in FieldDojo it has to be correct enough to show an inspector. A wire-gauge result can't be approximately right. So every table lookup was transcribed from the source standard, structured, cited, and then checked against worked examples from the codes themselves.
That work shows up nowhere in a demo, but you can measure it in the codebase. The calculation engines and their code tables are roughly 9,000 of the app's 28,000 lines of TypeScript, about a third of the source. Nearly half of that is regional variants — 76 files, around 4,500 lines, which exist because the same conductor or duct answers to different tables in the US, Canada, the UK, the EU, Australia, and New Zealand. The offline reference library is another 39 code-section pages on top. All of it was entered and checked by hand.
Offline-first is a similar kind of cost. It sounds like a checkbox but in practice it's a sync queue, a conflict policy (ours is server-wins with versioning), and database migrations that have to run unattended on phones we'll never touch. We wrote up those decisions separately.
What Was Nearly Free
To be fair to the stack, some things cost almost nothing:
- The second platform. One codebase shipped to iOS, Android, and iPad, which is why there's no Android row in the table.
- Expo's infrastructure. EAS builds, file-based routing with native tabs, and over-the-air updates came with the stack instead of being built.
- Calculators 20 through 57. Once calculation logic was a pure function returning its own formula and citation, adding a calculator was mostly adding its math and its data. The 57th cost a small fraction of the 7th.
What We Underestimated
Three honest entries from our own retrospective, expanded in the engineering post:
- Calculation abstraction came too late. We tolerated duplication across trade calculators longer than we should have, and the eventual refactor cost more than doing it early would have.
- Test coverage lagged the code. The pure-function architecture made testing easy; we still didn't write enough early, and edge cases in the conduit fill calculation surfaced in QA instead of CI.
- The design system was retrofitted. The shared CalculatorSection component arrived partway through, so earlier screens had to be reworked to use it.
None of these killed the budget. They moved it, which is the part most cost guides leave out.
The Backend We Didn't Build First
FieldDojo v1 had no backend at all: pure functions, local SQLite, no accounts. In the budget bands we use for MVP scoping, it started as the smallest shape and only grew a Hono + Postgres backend with auth and cloud sync after real usage justified one.
That sequencing was the biggest cost decision in the project. A backend on day one would have meant months of work for users who didn't exist yet. We built it later, once there was actual usage to justify it.
Turning a Teardown Into a Quote
This kind of breakdown is also just how we quote. Each line item above is the shape of a milestone: a deliverable, acceptance criteria, a fixed price, payment after approval. When we scope your app you get this same table for your product, with your line items, before you commit to anything.
If You're Budgeting an App
Install FieldDojo](https://fielddojo.com) and poke around; you'll form your own view of what the table above bought. If you're planning a build, [tell us what you're building and we'll do the same decomposition on your idea. You'll know which of your line items are the expensive ones before anyone writes code.