SSTIEM

Private proposal

Prepared for one recipient. Enter your access code.

Proposal from Thomas Tyler Hill of SSTIEM for a fitness member app build — executive summary, background, engineering principles, live work, build plan, investment, and next steps.

01 Executive summary

Thomas Tyler Hill.

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.

GMT+8AU-hours overlap
Full-timeOne project, dedicated
10 liveProduction platforms
BoutiqueCustom development

Your project, as I understand it

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.

What you receive

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

An operator who became a software architect.

Operations first

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.

Then software

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

Five principles run through every platform I ship.

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.

1Business rules live in settings, not code

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.

2One source of truth

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.

3Integrations stay loosely coupled

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.

4The staff side is a first-class product

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.

5Built for the second location from day one

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

Different industries, same problem

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

How I'd build your platform.

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.

The approach

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.

The two decisions your specification left open

Mobile: React Native, built with Expo

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.

Hosting: Cloudflare edge + OVHcloud Sydney

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.

The three systems your brief flags as make-or-break

Your own Section 15 singles these out for security and concurrency review. Same three I'd stress-test hardest.

The presale (1,000 cap)

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.

Ongoing capacity (1,700 ceiling)

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.

Peer-to-peer transfer

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.

The rest of the scope, point by point

02GymMaster sync + doorsMonths 1 & 4

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.

03HubSpot lifecycle + trial dedupMonths 1–2

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.

04Stripe billingMonth 2

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.

07Tiered booking windowsMonth 4

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.

08Free trialMonth 2

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.

09ReferralsMonth 4

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.

10Two-way feedbackMonth 5

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.

11Google review rewardMonth 4

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.

13Member dashboard + pushMonth 5

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.

15Environments, testing, reviewThroughout

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.

Month by month

Month 1 · FoundationsOne home for all your information — members, memberships, payments, bookings — wired to the test environments of all three systems. You'll see: the skeleton working, and weekly demos begin.
Month 2 · Money + membershipWeekly billing across your three tiers, the one-off access pass, personal-training add-ons and casual packs, the trial logic, and failed payments handled gracefully — everything staying in sync with GymMaster. Proof by month's end: a member signs up, pays, and appears correctly everywhere.
Month 3 · The capacity engineThe presale — waitlist, tokens, the 1,000 founding cap, and the 15%-for-life fallback — plus the ongoing 1,700 ceiling. Built as settings, so your next location reuses it. You'll see: a simulated launch rush that refuses to oversell.
Month 4 · Doors + bookingsTap-to-open at the door, the QR fallback, tiered booking windows for the recovery zone, the referral system, and the Google-review reward. Demo-ready: a door opening from the app, bookings obeying tier rules.
Month 5 · The apps take shapeThe member app on both platforms built from your Figma files, the web dashboard, the membership transfer flow, the feedback loop, and member stats. You'll see: the real app on your own phone.
Month 6 · Hardening + launchIndependent security review, load testing, App Store and Play submission with buffer for review cycles, documentation, and handoff. You'll get: the full package, live.

06 Investment

US$45,000, fixed.

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.

The build $7,500 / month × 6

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 already have a team Different conversation

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.

What's included

The full build end to end — every integration, every layer, production deployment.

Also separate

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.

After launch

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

The February date is achievable. Here's how we start.

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.

What I need from you

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.

What you receive in February

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