Building — and testing — a production mobile app, solo

01 What it does

Point a phone at a trading card. The app identifies it on-device, prices it against its own market data, and files it into a collection. Optionally, a deeper guided scan produces a grading prediction — the estimate a collector needs before paying $25 to send a card to a professional grader.

The engineering constraint that shapes everything: all image analysis runs on the device. No cloud inference, no per-scan cost, works with no signal at a card show. That pushes real computer-vision work into custom Kotlin modules instead of an API call.

CollectionValue history, movers, live pricing

Market MoversDaily signals computed in-house

Pre-gradingEvery scan keeps a full report

Scan reportDefect findings + honest confidence

Screenshots are from a development device. The collection shown is seeded test data — built from import/export testing and repeated duplicate scans — not a real portfolio, and the totals are not meaningful.

02 Quality engineering

There is no QA team here — which meant the automation had to be good enough to act as one. Four independent test layers run on every push, gated in CI, with a fifth layer of read-only probes running against production every night.

The four layers, and what each one is actually for

How the integration layer actually runs

The stack suite has an explicit rule behind it: no mocks for anything the database owns. Row-level security policies, SQL functions, triggers, constraints and grants are the parts most likely to be wrong and the least likely to be caught by a mock that returns whatever the test author expected. So CI stands up a real one.

Every run boots an actual Postgres through the Supabase CLI, applies the migrations, and binds the suite to whatever that instance reports — rather than to hardcoded environment values that can silently drift from it:

- name: Start local Supabase
  run: npx supabase start -x studio,imgproxy,inbucket,edge-runtime,logflare,vector

# Bind the suite to the instance that actually started, not to hardcoded values.
- name: Export stack keys
  run: npx supabase status -o env | sed 's/"//g' >> "$GITHUB_ENV"

- name: Stack suite
  run: npm run test:stack
  env:
    SUPABASE_URL: ${{ env.API_URL }}
    SUPABASE_ANON_KEY: ${{ env.ANON_KEY }}
    SUPABASE_SERVICE_ROLE_KEY: ${{ env.SERVICE_ROLE_KEY }}

Services under test are the same modules the app ships, not reimplementations. Getting React Native code to run under Node meant aliasing the native surface — AsyncStorage to an in-memory store, plus thin stubs for the Expo modules some services import at load time — so the service layer executes unmodified while the native surface it merely touches gets out of the way. Test files run serially rather than in parallel, because they share seeded database state; that is a deliberate trade of wall time for determinism.

The coverage gate is a policy, not a number

CI enforces 98% statements, 98% lines, 99% functions, 92% branches and fails the build below any of them. The rule attached to it matters more than the threshold: when a gate fails, it gets fixed with a test — never by lowering the number. A threshold that moves to accommodate untested code is not a gate.

A related habit, learned the hard way twice: a branch is never called green off a bare jest run. Local Jest and the CI invocation are different commands with different results, and only the exact CI command counts.

Security regressions become permanent tests

Every security finding — from a penetration review, an incident, or a code audit — is closed with a fix and a test that fails if the fix is ever reverted. The stack suite reads like an incident log, because that is what it is: privilege-column guards, paywall-bypass prevention, anonymous-enumeration checks, cross-user foreign-key isolation.

describe('training-data de-identification invariant (@security)', () => {
  it('training_candidates carries no user_id / scan_report_id join column', async () => {
    const cols = await sql<{ column_name: string }>(
      `select column_name from information_schema.columns
       where table_schema = 'public' and table_name = 'training_candidates'`,
    );
    const names = cols.map((c) => c.column_name);
    // The two join paths to a user, dropped by the de-identification migration.
    expect(names).not.toContain('user_id');
    expect(names).not.toContain('scan_report_id');
  });
});

Model-training images must never be joinable back to a user. That is a privacy promise in a policy document — and a policy document cannot fail a build. Asserting it against information_schema means the promise is enforced by CI: reintroduce the column, and the pipeline goes red.

A test written directly from an incident

A production trigger had a project URL hardcoded into a SQL function body. Because every CI run spins up its own database from the same migrations, that hardcoded URL meant test runs were firing outbound calls at the production service — a quiet cross-environment leak that showed up as a flood of gateway errors before anyone connected it to CI.

The fix moved URLs into a config table. The tripwire below is what makes sure nobody reintroduces the pattern — it greps every function body in the database for the production project reference:

it('no public function body hardcodes the prod project ref (tripwire)', async () => {
  const offenders = await sql<{ proname: string }>(
    `select p.proname
     from pg_proc p
     join pg_namespace n on n.oid = p.pronamespace
     where n.nspname = 'public' and p.prosrc ilike '%<prod-project-ref>%'`,
  );
  expect(offenders).toEqual([]);
});

CI, and a quality dashboard fed by it

The pipeline runs five jobs — lint/typecheck, unit, stack, edge functions, and a record-run job that collects every suite's results as artifacts and writes each run into a Postgres table. An admin panel in the app reads that table, so pass/fail, coverage, and covered areas have a visible trend over time instead of living only in expiring GitHub logs.

The same suites run again nightly on a schedule, plus the production canaries. A nightly failure opens or updates a dated GitHub issue automatically with what broke and when, so a silent overnight regression cannot go unnoticed.

03 Architecture

Feature-sliced React Native app, a strictly layered data path, five custom native modules, and a scheduled data platform that repairs itself.

App

• Strict layering, enforced by convention and review: screens never call the database. The path is always Screen → Hook → Service → Supabase client. Route files are thin shells with no logic.
• Feature-sliced structure — auth, scan, grading, collection, market, profile, admin — each owning its screens, hooks, services and schemas.
• State is split by kind: React Query owns every piece of server state; Zustand holds only client state. No server data in the client store.
• TypeScript strict, no any, no @ts-ignore, with zod validating both form input and model output.

On-device imaging

• Five custom Kotlin/CameraX Expo modules — capture, card detection, perspective warp, alignment, and frame fusion — because the required control over focus, resolution and frame timing does not exist in the JS layer.
• TFLite inference on-device via a native bridge, with ML Kit for text recognition during card identification.
• Models update over the air from object storage against a version table, so the model improves without an app-store release.
• Classical CV where determinism beats learning — border measurement for centering is arithmetic, not a model, and is therefore reproducible and explainable.

Backend & data platform

• Postgres with row-level security on every table, 14 Edge Functions for anything requiring a secret, and private storage buckets throughout.
• A self-hosted 157k-card catalog with multi-token strict-AND search, rather than depending on a third-party lookup API at request time.
• Nightly jobs that heal: page-level retries escalate to an automatic re-run, then to an archive re-pull, and finally to an opened GitHub issue. The pipeline attempts to fix itself before it asks a human.
• Secrets never reach the client. The app ships only public, RLS-protected keys; every privileged key lives in Edge Function environment variables.

04 Stack

05 Source access & status

Chasing Tens is a commercial product in pre-release, and the repository is private — it carries partner agreements under confidentiality terms alongside the application code.