Prepared for one recipient. Enter your access code.
01 Background
I'm an American developer and operator based in Bali, working GMT+8 with deliberate overlap into Australian hours. I run SSTIEM, a boutique that builds business operating systems — platforms, orchestration engines, automation layers, and the applications sitting on top of them. I'm not an agency, and I'm not a marketplace freelancer. With me you get my time, my projects, and my judgment on every architectural call.
From 2014 to 2018 I worked with NASA in data systems and field research for agricultural and soil programs — growing from field technician into technical manager. I deployed environmental monitoring hardware, pulled soil samples in the field, ran the analysis back at the lab, and helped turn raw field telemetry into research-grade data for white papers. When a measurement has to be right, the process around it matters more than any one clever part — that lesson has shaped everything I've built since.
After NASA, I went on to direct operations for residential housing in Seattle — running logistics and vendor budgets across 300+ tenants. From there I started businesses of my own, built some, sold some, and moved into service businesses, platforms, and media companies in Bali. That's where SSTIEM began.
SSTIEM has been alive for three years, and it started because I kept watching good businesses lose time to software that wasn't custom, wasn't navigable, and wasn't theirs. So I started building my own: infrastructures, operating systems, orchestration engines, and multi-tenant platforms that fit the way a business actually runs, not the way a template assumes it does.
We started with business owners, and now that same discipline runs across every vertical I build in — websites, applications, automations, and the protocols and engines underneath them. The nine platforms in the live-work section below are all live, all open to inspection, right now.
References available on request, including client contacts who can speak to delivery and communication directly.
02 Why I want this one
It's a gym, so here's my case in the language of one. Three muscles, all trained, all showing up for this build.
Knowledge is a muscle, and I've put mine through NASA labs, years running operations, and three straight years building software systems every day. I read your spec through that training, not as a checklist — I saw the whole machine: where a thousand people hitting join at once actually breaks a system, why a transfer has to be state and not a button. That's not luck. That's reps.
Health and fitness are a real part of how I live, not a category I picked. I believe in this build: the goal, the timeline, the spec you already put together. That's the heart of why my rate is competitive — not because I lack the ability, not because I undervalue the work, but because I want to be the one who builds this, specifically.
Will is the muscle nobody sees you train. Mine gets worked daily: long days finishing what I start with nobody standing over me, and years before that running operations where the deadline belonged to someone else's livelihood, not mine. A fixed date by February isn't a threat. It's the shape of work I already know how to hold.
03 Live work
I call them BOS builds, and they all carry the same four layers — which is exactly the four layers your brief describes. Across them I've worked custom databases, Postgres, SQLite and Supabase, multi-tenant payment infrastructure, hosting and security, and engines running large datasets concurrently.
The engine underneath: data model, orchestration between third-party systems, and the rules that decide what a user is allowed to do. Never hardcoded. Always settings an operator can change.
The staff-facing side. ATX Notary runs ten modules: appointments, clients, messages, finance, compliance, automation, SEO, audit logs, users. That is the shape of your admin portal.
The customer-facing account: bookings, history, documents, payments, support threads. Your member dashboard is this layer.
Built so a second location, brand, or business runs on the same architecture with different settings — I've run tenant infrastructure past 10,000 tenants. Your Section 5 requires exactly this: the presales engine reused at the next site.
A few more run the same way, even without their own card above. OMNIONE ingests continuously at high volume, with throughput, queueing, and state that stays correct under sustained concurrent load — the nearest thing I've built to your capacity-cap problem. Silk Route is a wholesale trade platform whose inventory and cross-border logistics had to stay accurate while the business moved under it. The Lead Intelligence Pipeline resolves identity across records that disagree with each other, the same shape as your HubSpot trial-abuse dedup. And TOMYLER takes a trend all the way through generative design into CAD and manufacturing output. Different industries, same discipline — I design every build as the operating system underneath a business, not a page for it to sit on.
04 How this actually gets built
Reading your brief carefully, the member app is actually the smallest piece. The real build is everything behind it: the backend where every rule lives, the glue that keeps GymMaster, HubSpot, and Stripe perfectly in sync, and the engine that makes the hard moments (a launch rush, a membership handoff) behave. Here it is in plain terms, month by month.
Not a front-end and a back-end bolted together — one complete platform. What members touch is the smallest piece: booking, paying, opening the door, referring friends. Underneath it is an admin portal that is a real internal operating system, not a login page — members, capacity, tickets, waitlists, campaigns, analytics, all in a browser. Underneath that is the backend platform doing almost all the actual work: one member upgrades their tier and eight things fire in order, validate, GymMaster, Stripe, HubSpot, app, notification, log, dashboard, and the backend conducts that every time, for every event. GymMaster, HubSpot, and Stripe stay exactly where they are; I build around them, which is realistically a third or more of the total engineering effort. And every rule that decides what a member is allowed to do ships as a setting you can change, not code you have to pay someone to rewrite.
With me, none of that gets lost in translation. I read a spec for its contradictions before they become change requests, I write the process documentation as the system takes shape, and I'll tell you when something won't work as written before it costs you a month. The person who decides how a rule gets enforced is the same person who builds it, tests it under load, and explains it to you afterward — and I'm treating this as the start of a relationship, not a single transaction. You have future locations and future ideas coming; what you get with me is a vendor you can call on for both.
Your specification runs seventeen sections. Here is what each one asks for, what it means in practice, and how I would build it.
What it asks forYour three systems stay exactly where they are — I don't replace anything you already pay for.
How I would build itI build the member app, the dashboards, and the orchestration layer underneath that keeps GymMaster, HubSpot, and Stripe talking to each other correctly. Your Figma designs get built as drawn.
What it asks forEvery membership event stays in sync both ways, and the app opens your doors through GymMaster's own system.
How I would build itJoining, upgrading, downgrading, pausing, cancelling — all flow both ways between the app and GymMaster through webhook-driven sync, so the two never disagree and GymMaster stays the system of record. For the door, the primary path is phone-near-door, member taps, the app calls GymMaster's door trigger. The rotating QR code is the fallback for when the internet at the door is patchy — I'll pressure-test the handoff between the two hardest, because 5am at a locked door is the moment a member judges the whole app.
What it asks forHubSpot becomes your memory — waitlist, lead lifecycle, and who's already used a trial.
How I would build itI've built inside HubSpot with custom code actions before, so identity dedup against HubSpot's record — not my own database — is the default pattern, exactly as your brief specifies. Nobody earns a second trial by signing up with a new email address.
What it asks forAll the money: weekly memberships across three tiers, the joining fee, add-ons, casual packs, Apple and Google Pay.
How I would build itI've shipped live Stripe subscription billing before. Every charge carries an idempotency key so a retry can never double-bill, and every webhook updates membership status the instant it fires — that discipline is my default for payments now, not something I'm learning on this build.
What it asks forYour launch day has to sell exactly 1,000 memberships, not 1,001, no matter how many people hit buy in the same second.
How I would build itThis is the engine I take most seriously in your whole brief. The only referee that can't be fooled is the database itself, so I enforce the cap at the database level — row-level locking, a checkout hold that reserves a slot only while someone is actually paying, released the instant they don't finish. Cap number, token window, and fallback percentage all live as settings, because you told me this campaign runs again at your next site.
What it asks forThe gym never sells past 1,700 members, and a cancelled spot opens instantly for the next person in line.
How I would build itSame locking discipline as the presale, running continuously instead of once. A slot releases the moment GymMaster confirms a cancellation, and a new signup can't claim it until the database says it's actually free — the same transaction-safe pattern, not a second system.
What it asks forDifferent membership tiers get different advance-booking windows for the sauna and cold plunge.
How I would build itFeature-gated by tier, config-driven by design — this is how I build tier logic by default, specifically so changing 7 days to 5 later never means touching code.
What it asks forOne free week per person, for life — not per email address.
How I would build itDedup runs against HubSpot's record, exactly as specified, with a backend toggle controlling whether trials are even offered. The day-8 conversion to paid runs on a scheduled job, not a hope, and a caught duplicate routes straight to your team.
What it asks forA member invites a friend; when the friend joins and pays, the member gets a free month.
How I would build itA referral system is a feature gate plus a reward trigger — I've built several. The part that actually matters is making sure the reward only fires once the referred member has genuinely paid, not just signed up, and that the referring member's ID lands on the new profile in GymMaster.
What it asks forA real two-way conversation, not a one-way contact form.
How I would build itBuilt as a ticketing model with a thread and a status, the same pattern I use for any two-way messaging system — media goes to object storage, and a reply from your team fires a notification straight back into the member's app.
What it asks forA rating captured in-app, synced out to your Google listing, with an automatic reward.
How I would build itStraightforward — a rating capture with a reward trigger attached. I've built the same shape before for review-incentive flows. Four or five stars applies 7 days free to the next bill automatically.
What it asks forOne member hands their membership to another, cleanly, without breaking continuity or the capacity count.
How I would build itI treat this as a state machine, not a form — the real engineering here is defining who's allowed to give, who's allowed to receive, the exact moment the handoff becomes final, and what happens if either side drops it mid-pass. Every transition writes an audit row, and the capacity count gets read and written inside the same transaction as the transfer, so it can never drift mid-handoff. In GymMaster it lands as a profile transfer, not a cancel-and-rejoin, so membership history stays intact. The incoming member sets up their own payment method, per your own recommendation — cleaner billing history.
What it asks forTenure, check-ins, and referrals, plus a reusable onboarding walkthrough and push notifications.
How I would build itRead-only views pulling from data the backend already tracks, so there's no second source of truth to keep in sync. The onboarding walkthrough is a component you can edit and reuse at the next location, which is how I build onboarding by default now. Push runs through Firebase for class reminders, billing, capacity openings, and lifecycle events.
What it asks foriOS and Android apps from your Figma files, plus a browser dashboard sharing the same backend.
How I would build itMy recommendation is React Native, built with Expo — one shared TypeScript codebase compiled for both stores, sharing real code with the web dashboard instead of two teams building the same logic twice. Against a fixed February date, that's the business logic written once, not twice, with genuine native performance and direct Bluetooth and push access at the door, not a compromise version of either. Gate access stays native-app-only, deliberately, exactly as your brief specifies. If any single piece needs native code beyond that, that piece goes native — the build serves the spec, not a framework preference.
What it asks forSeparated environments, Australian hosting, independent security review, and full testing including a simulated launch rush.
How I would build itMy recommendation is Cloudflare on the edge for DNS, CDN, and security, with a dedicated VPS in OVHcloud's Sydney region underneath it — the one provider in my usual toolkit with an actual Australian datacenter, which matters directly for your members' health-waiver data. The VPS runs a self-managed Postgres instance configured specifically for the row-level locking items 5 and 6 depend on; that's more hands-on than a fully managed database, and I'd rather say that plainly than imply otherwise — the trade-off buys lower cost and keeps me directly responsible for how the locking is configured. Before launch, someone who isn't me tries to break the caps, the money, and the transfer — I already have that reviewer in mind and will name them on request, because a builder marking their own homework isn't a review. Staging and production stay fully separated, everything encrypted in transit and at rest, and the concurrent-load test happens on a simulated presale before your real one.
What it asks forMid-August start, delivered by end of February.
How I would build itReal, because it's already sequenced month by month above — store review time is built into the schedule, not hoped for at the end. The one thing that moves it is a late handoff of the Figma files or the GymMaster, HubSpot, and Stripe sandbox credentials.
One line answers section 17 directly: the technical approach and hosting provider are named above with reasoning, the total cost is in section 06, kickoff assumptions are in section 07, and the timeline is confirmed in item 16 above.
05 Where SSTIEM sits
Published Australian agency rates for this class of work. Across the roughly 1,000 hours this build needs, that lands between AUD $150,000 and $300,000 — four to eight people, some of them junior, and an account manager between you and the work.
You talk to me. I build. I own the deliverables. I bring special attention to detail because I'm creative and I care, and I have close collaborators I can pull in when it genuinely helps. For this level of single-person ownership, the rate usually runs much higher.
Cheap, fast, priced per task: no opinion on your architecture, no stake in your outcome, and gone at handover.
I'm offering a competitive rate because I like this project and I'm confident in what I can deliver — not because this is bargain work.
06 Compensation
That's the full scope in your brief, delivered inside your fixed window — roughly a thousand hours, full-time, across six months. The arithmetic is open on purpose: the price is built from the scope, not guessed at it.
Roughly 1,000 hours at an effective US$45 an hour, all in. Billed as a simple monthly retainer, so you never bet the budget on trust — you pay for the month in front of you, and you watch it get built.
Engineering, architecture, integrations, testing, and deployment of a production-ready platform — everything needed to deliver is included, no separate line items to negotiate later. No 50% deposit, no invoice ambush. The first month starts it, and every month after that you've already seen what the last one produced. Weekly written updates, a weekly call if you want one, and a live build you can open any time. If a phase ever genuinely needs an extra pair of hands, we talk first. Nothing changes without your sign-off.
If you have developers you'd like on this, or you'd rather bring me in as a technical lead inside your team, that's a different scope and a fair conversation — happy to have it.
Everything required to deliver the platform end to end — the full build, every integration, and production deployment.
Apple and Google developer accounts, store fees, and the work of getting the app live in both stores. A small, defined extra scope we agree together.
Ongoing maintenance and technical stewardship: a retainer conversation for later, once you've seen how I work.
For context: at published Australian agency rates of AUD $150–330 an hour, this scope prices out well past AUD $150,000. The judgment, the architecture, and the accountability stay senior, and stay mine.
07 A few things to settle
Is February achievable? Yes. Mid-August start, delivery by end of February, with the App Store and Play review cycles absorbed inside the buffer. I have shipped live Stripe subscription billing, worked closed third-party booking APIs of GymMaster's class, and built inside HubSpot with custom code actions — the three integrations this build stands on.
The total number: US$45,000, all in — engineering, architecture, integrations, testing, and deployment. Per section 06. Store fees are separate, per the note below.
What I need at kickoff: the Figma files, and sandbox credentials for GymMaster, HubSpot, and Stripe. A late handoff on those is the only thing that moves the date.
What lands in February: both apps submitted, the web dashboard live, the backend running, full documentation, credentials, and the codebase, all yours.
The Apple Developer account: I'd recommend publishing under your own account, so the business owns its own listing — I'll run it either way.
References: I can arrange calls on four of these builds — Hillside Cleaning, NEOS / Nuanu, ATX Notary, and Tymeline Studios. Say the word and I'll make the introductions.
Design coverage — how many Figma screens are in the handoff, and is the admin dashboard designed too, or only the member app?
GymMaster — is the full API documentation and a sandbox available, and are the door-trigger and membership-transfer endpoints confirmed working, not just documented?
HubSpot & Stripe — are the workflows and subscription products already configured, and who owns maintaining the HubSpot side after launch?
Launch load — how big do you expect the waitlist to be at the presale moment? It changes how hard I load-test the rush.
Your team — is anyone on your side joining the build, or is this a clean solo engagement?
After launch — support, warranty window, and ongoing stewardship: talk now, or once the build has spoken for itself?
Thomas Tyler Hill · SSTIEM
Bali, Indonesia · GMT+8 · sstiem.pro@gmail.com