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 the individual features are well understood — the complexity is in making them behave as one reliable platform. 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. If those systems disagree even briefly, the result is wrong memberships, failed bookings, and billing disputes — that, more than the app itself, is the problem this proposal solves.
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 for the same account on desktop; 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
My background isn't traditional software engineering. I started in scientific field operations with NASA-supported agricultural research, where reliability, repeatability, and accurate data mattered every day. I later directed residential operations in Seattle — 300-plus tenants — which taught me how software affects the people actually running a business.
That combination led me to software architecture: I build systems around how businesses operate, rather than asking businesses to adapt to off-the-shelf software. Three years ago that became SSTIEM, my studio in Bali.
I call these platforms business operating systems — nothing exotic, just the software that runs a business day to day: customers, staff, bookings, payments, notifications, and reporting in one connected place. Ten are live in production today, and every one is open for you to click through.
This project sits squarely inside the type of operational software I most enjoy building.
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.
In this build that means the 1,000 presale cap, the token window, the 15% fallback offer, the 1,700 ceiling, the 7-day / 3-day / 24-hour booking windows, and the trial on-off toggle all live on a settings screen. Change one and it takes effect immediately, with the change logged. Nothing on that list requires a developer.
Memberships live in GymMaster, payment records in Stripe, marketing history in HubSpot. The platform reads and coordinates; it never keeps a second copy of membership status. That's the difference between preventing sync problems and patching them — two systems can never disagree about whether someone is a paying member, because only one system holds the answer.
The door check depends on GymMaster alone, so a HubSpot outage can never keep a member outside at 5am. Failed calls to any external system queue and retry until they land. A failure in one system delays one feature; the rest of the platform doesn't notice.
Your team will spend more hours in the operational tools than any single member spends in the app. In this build those tools are the trial-duplicate intercept screen, feedback replies, transfer oversight, and the settings screens above — and they get the same design and testing standard as the member-facing screens.
Every cap, window, and offer is stored per location, not globally. When you open the next site, its presale runs on the same tested engine with its own numbers, and its staff and members live on the same system with their own settings. The build cost is code; the second location only pays for configuration.
04 Live work
These platforms span different industries, but they solve the same class of engineering problems your specification describes: coordinating multiple systems, enforcing business rules, handling payments, managing bookings with hard limits, and giving operators one place to run the business. That's why I recognized your engineering challenges immediately, even though the domain is different — most of what you're asking for has a working precedent here.
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 these integrations follow patterns I've already used successfully in production, so your billing and sync logic isn't invented from scratch.
I recommend React Native because it lets the mobile apps and the web dashboard share their business logic — written once, maintained once — without sacrificing the native capabilities this project requires: real performance, Bluetooth at the door, and push notifications. Gate access stays native-app-only, as your specification requires, and if any single piece needs fully native code, that piece gets it.
I recommend a dedicated server in OVHcloud's Sydney region, behind Cloudflare for security and delivery, because your health-waiver and member data must stay in Australia. The database is self-managed rather than outsourced — a deliberate trade that costs more of my attention and buys direct control over the transaction guarantees the capacity caps depend on.
Every project has risks. These are the ones I'd watch closest — your own Section 15 flags the same three for security review — and third-party outages and failed payments are already absorbed by the retry patterns in my principles above.
During a launch rush, hundreds of people can reach checkout in the same second, and the thousandth membership must be sold exactly once. That guarantee is enforced in the database rather than the app, because that's the only place it can be absolute. A checkout hold reserves a slot only while someone is actively paying; unredeemed tokens die the instant the cap hits; latecomers route to the 15%-for-life fallback. Cap, window, and fallback are per-location settings, because this engine runs again at your next site.
The same database-level guarantee 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.
Transfers look simple on paper, but two accounts, payments, booking rights, and the capacity count all change hands at once — which makes this one of the highest-risk workflows in the platform. It's built as a sequence of verified states: eligibility, identity verification, a defined point of no return, and handling for either party dropping out mid-transfer. Both parties are notified at each step, every step is auditable, and GymMaster records a profile transfer so membership continuity survives. The incoming member sets up their own payment method — your spec's own recommendation, and the cleaner billing separation.
Every lifecycle event — join, upgrade, downgrade, suspend, cancel — syncs both ways, with GymMaster the system of record; class and open-mat bookings run on GymMaster's own engine while the app applies the tier rules. For the door, tap-to-open triggers GymMaster's access system, with a rotating QR code as the fallback for patchy connectivity. That handoff is the one I'll test 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 — so 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. Payments are built so a retry can never charge twice, and membership status updates the instant any payment event lands.
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, with the one-month reward released only once the referred member has actually paid — and the referrer's ID recorded on the new member's GymMaster profile, as your spec requires.
A two-way conversation with threads and status, not a contact form. Members can attach photos, and your team's reply lands back in their app as a notification.
Captured in-app, synced to your Google listing; four or five stars applies seven days free to the 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 module you can edit per location, and push notifications cover class reminders, billing, and capacity openings.
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
Billed in milestone-based installments, based on the scope described in this proposal. You work directly with me throughout; specialist expertise is brought in only where it improves the outcome, such as the independent security review before launch.
This investment covers the complete engineering engagement, along with the development infrastructure reasonably required to deliver it. It assumes the specification remains materially unchanged, third-party platforms remain available under substantially similar terms, and project assets arrive on schedule. The objective is to eliminate surprises — for both of us.
Each payment corresponds to the phase completed before it — you're paying for demonstrated progress, not time. US$7,500 follows each of the first five completed monthly milestones, and the final US$3,000 is invoiced at handover, documentation, and production launch — so this engagement stays tied to your launch, all the way to the end.
This engagement isn't priced around individual screens. It's priced around delivering a production-ready platform your business can operate, evolve, and own — the engineering decisions, testing, documentation, and operational foundation behind your launch and what comes after it.
Architecture, engineering, every integration, testing, deployment, documentation, and launch support — end to end.
Apple and Google developer accounts, production hosting, and commercial third-party subscriptions stay in your name — so the business keeps ownership and direct control after launch.
If the scope changes materially, or external platforms introduce significant new engineering work, we review the impact together before that work begins. Nothing affecting budget or timeline proceeds without your approval.
There is no vendor lock-in. At handover the platform is fully yours — source code, documentation, deployment pipeline, credentials, and an administrative guide — and you're free to continue with your own team or another developer at any time. My role after launch is entirely optional; ongoing stewardship, if you'd like it, is scoped together once the platform is live.
If the investment needs to fit your plans differently, raise it on our first call — the scope can be phased, with the launch-critical platform still landing by February. The structure is designable; the date and the quality aren't.
07 Questions & next steps
A mid-August start delivers by end of February, with both app-store review cycles absorbed inside the schedule's buffer. None of the questions below block a yes — they can all be settled in our first conversation.
At kickoff: the Figma files, including how far they cover the web dashboard, plus sandbox credentials for your three systems. A late handoff on those is the only thing that moves the delivery date.
GymMaster — 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, and who maintains HubSpot after launch.
Launch load — your best estimate of waitlist size at the presale moment, which sets how hard the launch-rush simulation gets pushed.
Hear it from my clients. The owners behind Hillside Cleaning, NEOS / Nuanu, ATX Notary, and Tymeline Studios are happy to take a reference call — just ask, and I'll connect you.
One call sets it in motion. We walk through this plan together, settle the kickoff questions, and the build starts mid-August.
My goal isn't simply to deliver an app by February. It's to hand your team a platform they can confidently operate on day one, adapt as the business grows, and keep building on for years without rewriting its foundation.
Thomas Tyler Hill · SSTIEM
Bali, Indonesia · GMT+8 · sstiem.com · sstiem.pro@gmail.com