Prepared for one recipient. Enter your access code.
01 Executive summary
I build custom software that becomes the operational backbone of a business. Rather than replacing systems like GymMaster, HubSpot, or Stripe, I build the platform that connects them, automates the workflows between them, and gives the people running the business direct control over how everything behaves.
You're commissioning a native member app for iOS and Android plus a web dashboard, both on one backend, with your three existing systems kept in place. Most of it is straightforward to build. Success rests on four harder problems: selling exactly 1,000 founding memberships during a launch rush, holding a 1,700-member ceiling around the clock, keeping three separate systems in constant agreement about every member, and letting one member hand their membership to another without breaking any of it.
My recommendation, in one line: keep your three systems as the engines, build one platform that coordinates them, and store every business rule as a setting — so that opening your second location becomes a configuration exercise instead of a rebuild.
By end of February, ahead of your March launch: the member app on iOS and Android, built from your Figma designs and submitted to both stores; the web dashboard giving members that same account in a browser; and the backend running in production behind them — the presale and capacity engines, the booking rules, the membership-transfer workflow, and all three integrations, tested under a simulated launch rush and checked by an independent security reviewer before it handles real money.
You own all of it: the complete codebase, the documentation, and every credential. And because the business rules ship as settings, your team can change caps, booking windows, and offers without calling a developer.
The engagement is direct — you and me, start to finish — and you watch it happen: weekly written updates, a call whenever you want one, and a live staging build you can open any time.
References available on request — client contacts who can speak to delivery and communication directly.
02 Who I am
From 2014 to 2018 I worked with NASA on agricultural and soil research programs, moving from field technician to technical manager. The work was scientific rather than software: deploying monitoring hardware, validating field data, turning raw telemetry into research-grade datasets. What it actually taught me was how to design repeatable processes that produce reliable results — the same skill that makes software dependable.
After NASA I directed operations for a residential housing portfolio in Seattle: 300-plus tenants, vendor budgets, staff, and the daily work of keeping a business running. That job taught me that software succeeds or fails on how well it supports the people operating the business — a lesson most developers never learn from the inside.
I moved into building software because I kept watching good businesses forced to adapt themselves to tools that were never designed around how they actually work. Three years ago that became SSTIEM, my studio in Bali, where I design each platform around the way the business behind it operates.
When I say a platform is a business operating system, I don't mean anything exotic. I mean the software that runs the business day to day — customers, staff, bookings, payments, notifications, and reporting in one connected place. Ten of them are live in production today, and every one is open for you to click through.
Health and fitness are also a genuine part of how I live, which is part of why my rate on this project is competitive: I want to build this one specifically, and I'd like to still be your developer when the second location opens.
03 How I build software
A list of technologies tells you less than how someone makes decisions. These are the five I build by, and you'll see each one at work in the plan below.
Your booking windows, caps, and offers will change over time. When a rule lives in configuration, you change it yourself from the admin side. When it lives in code, you pay a developer and wait. Everything your specification marks as configurable ships as a setting.
GymMaster already owns membership data, so nothing I build duplicates it. Each system keeps one clear job, and the platform keeps them in agreement. That's how sync problems get prevented instead of patched.
If HubSpot has an outage, the door should still open. Every connection is built so that a failure in one external system degrades one feature — never the platform.
Your team will spend more hours in the operational tools than any member spends in the app. Intercept screens, feedback responses, and settings get the same quality bar as the member-facing screens.
Opening another site shouldn't mean building the software again. The platform is structured so a new location is a new set of settings — its own caps, staff, and members, on the same system.
04 Live work
Every platform in this carousel started the way your project is starting: a real business running on disconnected tools, needing one system built around how it actually operates. Hillside Cleaning needed bookings, payments, client accounts, and support tickets working together. ATX Notary needed hard daily booking ceilings and tier-based pricing. Nuanu needed a polished public face running on a real operations backend. The industries differ, but they're all solving the same problem: giving the business a single operating system instead of a collection of disconnected tools.
Because of that overlap, most of what your specification asks for has a working precedent here — payment workflows that stay correct, outside systems kept in agreement, booking rules with hard limits, and settings the owner changes without calling a developer. Tap any card to see what it proves, or open the live site itself. Two more platforms run without a card: OMNIONE, which ingests high-volume data continuously and stays correct under sustained concurrent load, the closest thing I've built to your launch rush; and the Lead Intelligence Pipeline, which resolves identity across records that disagree, the same job as your trial-abuse detection.
05 The build plan
After reading your specification, I don't see this as a mobile app project. It's an operations project with a mobile interface. The screens are the straightforward part — the outcome depends on the business rules, integrations, and workflows that keep memberships, bookings, payments, and door access synchronized. That's the kind of problem I most enjoy solving.
One platform, three layers. The native app is what members touch: booking, paying, opening the door, referring friends. The web dashboard gives them that same account in a browser. The backend underneath does the real work: when a member upgrades their tier, it validates the change, updates all three of your systems, refreshes the app, sends the notification, and writes the audit log. Every time, for every event.
Your existing systems stay exactly where they are, because each one already does its job well. GymMaster remains the source of truth for memberships. Stripe keeps handling payments. HubSpot keeps the marketing and lead history. What's missing is the layer that keeps them in step — that's most of the engineering in this project, and because I've shipped live Stripe billing, synced membership systems through closed third-party APIs, and built inside HubSpot's own workflow engine before, your integrations build on patterns that have already worked in production rather than starting from scratch.
One shared TypeScript codebase compiled for both stores, sharing real logic with the web dashboard instead of two teams writing everything twice. Against a fixed February date, that's the business rules written once, with genuine native performance and direct Bluetooth and push access at the door. Gate access stays native-app-only, as your brief requires, and if any single piece needs to go fully native, that piece does.
Cloudflare for DNS, CDN, and security; underneath it, a dedicated VPS in OVHcloud's Sydney region — a true Australian datacenter, which your health-waiver and member data residency requirement makes non-negotiable. It runs a self-managed Postgres tuned for the row-level locking the caps depend on. That's more hands-on than a managed database, and I'd rather say so plainly: the trade buys lower cost and direct control over the locking.
Your own Section 15 singles these out for security and concurrency review. Same three I'd stress-test hardest.
The only referee that can't be fooled is the database, so the cap is enforced there: row-level locking, a checkout hold that reserves a slot only while someone is actively paying, released on abandonment or timeout. Unredeemed tokens invalidate the instant the cap hits or the window closes; latecomers route to the 15%-for-life fallback. Cap, window, and fallback all live as per-location settings, because this engine runs again at your next site.
The same locking discipline running continuously. A slot opens the moment GymMaster confirms a cancellation; at capacity, signups are blocked before the payment screen and routed to the waitlist. Staff and instructors are excluded from the count, per your spec.
A state machine, not a form: eligibility, identity verification of the incoming member, a defined point of no return, and handling for either party dropping out or a payment failing mid-transfer. Every step notifies both parties and writes an audit row, the capacity count is updated inside the same transaction, and GymMaster records it as a profile transfer so membership continuity survives.
Every lifecycle event — join, upgrade, downgrade, suspend, cancel — flows both ways through webhook-driven sync, with GymMaster the system of record. Class and open-mat bookings follow the same principle: GymMaster's own booking engine does the scheduling, while the app surfaces availability and checks the tier rules before passing a booking through. The door: Bluetooth proximity plus tap-to-open calls GymMaster's v3 door trigger; a rotating, time-limited QR validated by their Gatekeeper API covers patchy connectivity. I'll pressure-test that handoff hardest, because 5am at a locked door is where the app gets judged.
Lead stages, waitlist capture, and the persistent contact record used to catch repeat trial attempts. I've built inside HubSpot with Custom Code Actions before — nobody earns a second trial with a new email address.
Weekly subscriptions on all three tiers, the $34.95 access pass, personal-training add-ons, casual packs, Apple and Google Pay. Every charge carries an idempotency key so a retry can never double-bill; every webhook updates membership status the instant it fires.
Recovery-zone booking at 7 days for Full Pass, 3 days for Gym Only and BJJ/MMA, 24 hours for casual passes — all three values backend-configurable, exactly as specified, so adjusting them never means a code change.
Seven days, once per person for life, with a backend toggle. Day 8 at 12:01am converts to the first weekly billing cycle on a scheduled job; a caught duplicate is blocked and routed to your team's intercept screen.
A unique link per member. The one-month reward fires only once the referred member has actually paid, and the referrer's ID is pushed into the new GymMaster profile for tracking.
A real ticketing model with threads and status, not a contact form. Photo uploads land in object storage, and your team's reply fires a push notification straight back into the member's app.
Rating captured in-app, synced to your Google listing; four or five stars applies seven days free to the member's next billing cycle automatically.
Tenure, check-ins, and referrals read from data the platform already tracks — no second source of truth. The onboarding walkthrough is a reusable, backend-configurable module, and push runs on Firebase for class reminders, billing, capacity openings, and lifecycle events.
Staging and production fully separated, each with its own test and live configuration of all three systems; automated build and deployment; encryption in transit and at rest. Before launch, an independent reviewer — someone who isn't me — tries to break the caps, the money, and the transfer, and the launch rush is simulated under concurrent load before your real one.
06 Investment
That covers the full scope in your specification — architecture, implementation, every integration, testing, the independent security review, and both store submissions — delivered inside your fixed window and billed monthly across the six months.
Here's how the engagement works. You work directly with me for the whole build. I own the architecture, the implementation, and the delivery, and I bring in specialist collaborators only where they genuinely add value — the independent security reviewer before launch being the main one. Billing follows the work: each month you've already seen what the previous month produced before the next one begins, so the project earns its budget as it goes. If any phase would genuinely benefit from an extra pair of hands, we talk about it first, and nothing about scope or cost changes without your sign-off.
One number, everything included: engineering, architecture, integrations, testing, and production deployment. There are no separate line items to negotiate later, and the first month's invoice is what starts the build.
If you have developers you'd like on this, or you'd rather bring me in as a technical lead inside your own team, that's a different scope — and a conversation I'm happy to have.
The full build end to end — every integration, every layer, production deployment.
Apple and Google developer accounts and their store fees, plus the work of getting both apps live in the stores — a small, defined scope we'll agree on together.
Ongoing maintenance and technical stewardship — a retainer conversation we can have at kickoff, or once the build has spoken for itself.
07 Questions & next steps
A mid-August start delivers by end of February, with the App Store and Play review cycles absorbed inside the schedule's buffer. The questions below are what I'd want settled at kickoff — none of them block a yes, and all of them can be finalized in our first conversation.
At kickoff: the Figma files, plus sandbox credentials for your three systems. A late handoff on those is the only thing that moves the delivery date.
Design coverage — how many Figma screens come in the handoff, and does it cover the web dashboard as well as the member app?
GymMaster — full API documentation and a sandbox, and confirmation that the door-trigger and membership-transfer endpoints are live and tested, not just documented.
HubSpot & Stripe — whether the workflows and subscription products are already configured on your side, and who maintains the HubSpot side after launch.
Launch load — your best estimate of waitlist size at the presale moment, which sets how hard the launch-rush simulation gets pushed.
Your team — whether anyone on your side joins the build, or whether this runs as a solo engagement end to end.
The platform, live: the iOS and Android apps submitted for review, the dashboard live on the web, and the backend running in production behind them.
Ownership: full documentation, all credentials, and the complete codebase, handed over to you.
The Apple Developer account: I'd recommend publishing under your own account so the business owns its listing — I'll run it day to day either way.
References before you decide: four of these builds can speak directly — Hillside Cleaning, NEOS / Nuanu, ATX Notary, and Tymeline Studios. Say the word and I'll set up the calls.
Next step: a call to walk through this plan and settle the questions on the left. If the answers are ready, the build starts mid-August.
Thomas Tyler Hill · SSTIEM
Bali, Indonesia · GMT+8 · sstiem.pro@gmail.com