T Trackmint Docs
🔍Search docs…⌘K
🔍
Hands-on Guides ↓ Download original doc (.md)

How Trackmint Is Built & Shipped — the complete guide

Everything about how this product gets made: who does what, the tech stack, every environment, every key and token, and the exact journey code takes from an idea to your iPhone. Written so anyone can follow it.

1. Who does what (the team model)

You (Barry) are the product owner: you describe features in plain words and make decisions. Claude (Cowork/Claude Code) is the designer AND the engineer: it designs the screens, writes the code, tests it, and ships it. Claude is also a worker inside the product (the AI employee on the board). Content tools (Higgsfield for video, this doc library for text) are the marketing department, also run by Claude under your approval. There is no human engineering team — that’s the point, and the story.

2. The tech stack (what it’s made of)

One codebase, four products. The app is written in TypeScript using React Native + Expo — write the screens once, and the SAME code becomes the iPhone app, the Android app, and the web app. Firebase is the backend: Auth (login accounts) and Firestore (the database — one record per workspace, plus the config/billing control record). There is deliberately no server of our own — the app talks straight to Firebase, which is why hosting costs $0 today. Git records every change (13+ commits); pushing to GitHub (waiting on your token) adds cloud backup and opens the door to automatic CI later. Quality is guarded by the QA suite: 15 robot-driven workflows / 94 checks that replay real business scenarios against every build.

3. The pipeline — how code becomes an app (the diagram)

1 · You describea feature (plain words) 2 · Claude codes itReact Native + TypeScriptthen runs 94 QA checks 3 · Git commit(→ GitHub when ready) 4a · Web app 4b · EAS build Your websiteapex.socialtokens.site TestFlight(builds 7…15) App Store(release when ready) Android APK(→ Play Store later) Firebase (the backend both apps talk to)Auth = accounts · Firestore = workspaces/{uid} data + config/billing (the monetization switch) · rules = who may read/write

In words: you describe → Claude writes React Native code and tests it → git commit → two outputs from the same code: (a) expo export produces the web app, copied to your website; (b) EAS Build (Expo’s cloud build farm) compiles the real iPhone app on Apple hardware in the cloud, signs it with your certificates, and auto-submits to TestFlight. From TestFlight, promoting to the public App Store is a button in App Store Connect (add screenshots + description, submit for Apple review). Android takes path (b) too — the same EAS command with --platform android makes an APK now, an AAB for the Play Store later (doc 36).

4. The environments (where things live)

  1. Claude’s cloud workspace — where code is written and the QA suite + video generator run. Ephemeral; everything important is committed to git.
  2. Your VPS (Hostinger, apex.socialtokens.site) — serves the website + docs + videos + admin console + web app; also the machine that runs EAS build/submit commands (it holds the signing credentials).
  3. EAS cloud (expo.dev, account bazdev0001) — Expo’s build farm; compiles iOS/Android, stores the Android keystore.
  4. Apple App Store Connect — receives builds, runs TestFlight, and (later) the public App Store listing.
  5. Firebase project trackmint-a8604 (Spark plan, $0) — Auth + Firestore. This is production data.
  6. Your iPhone / any Android phone — TestFlight app + APK installs.

5. Every key & token (what unlocks what)

Credential What it unlocks Where it lives
EXPO_TOKEN Runs EAS builds/submits without logging in VPS (passed inline to each build command)
Apple ASC API key (.p8, ID K3DJLR35C6 + issuer ID) Auto-submitting builds to TestFlight Path configured in eas.json (submit profile)
iOS distribution cert + provisioning profile Signing the iPhone app Managed by EAS (“local credentials”)
Android keystore Signing the Android app Generated & stored by EAS
Firebase web config (apiKey etc.) Lets the app find your Firebase project — public by design, NOT a secret Inside the app code
Firestore security rules The real security: who may read/write what Firebase Console (owner-only writes to config)
Firebase service-account key The admin & agent CLIs (bypasses all rules) ⚠️ NOT YET CREATED — you generate it (Console → Service accounts)
GitHub Personal Access Token Pushing the 13 commits to a TrackMint repo ⚠️ NOT YET PROVIDED
Higgsfield API key (ID 02bb2287-…) AI video generation for marketing Recorded; needs its paired secret to use
Google Play service-account JSON Automated Play Store submissions Later — after you create the Play Console account

Rule of thumb: the Firebase web config is safe to publish; everything else in this table is a secret — never commit any of them (the repo’s .gitignore already blocks the key filenames).

6. The admin tool — how it’s delivered (decision)

Your instinct was right: it’s now a web app — the Admin Console at /admin.html on your website. Sign in with your owner account and you get the billing master switch, tier prices, trial length, vertical pricing, and the paywall message — usable from any browser, nothing to install, and safe: database rules mean only YOUR account’s writes are accepted (anyone else who finds the page gets “denied”). It is NOT a separate App Store product — that would be slower to update and overkill for one operator. The CLI (trackmint-admin.js, doc 30) stays as the deep tool for what browser rules rightly can’t allow: managing OTHER users (create/delete/passwords) and editing other people’s workspace records — that needs the service-account key. So: web console for everyday control, CLI for surgery. Both exist today.

7. Release checklist (the routine, every version)

Code + tsc clean → 94-check QA suite green → web export → deploy website/webapp → eas build --auto-submit (iOS; Android APK on demand) → verify “uploaded to App Store Connect” in the build log → commit → update docs. This exact routine has shipped builds 7 through 15.