SSTIEM

Private proposal

Prepared for one recipient. Enter your access code.

Proposal from Thomas Tyler Hill of SSTIEM for a fitness member app build — background, live work, plain-language build plan, and pricing.

01 Background

Thomas Tyler Hill.

I'm an American developer and operator based in Bali, working GMT+8 with deliberate overlap into Australian hours. I run SSTIEM — a custom creative boutique focused on building systems, workflows, automations, and applications. I'm not an agency, and I'm not a Fiverr freelancer. With me you get my time, my projects, and my curation.

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

Before software, I ran operations.

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 was born out of need.

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 friendly. So I started building my own: infrastructures, operating systems, and multi-tenant applications that fit the way a business actually runs.

We started with business owners, and now we offer everything we've built across all kinds of verticals — websites, applications, automations, and the protocols and systems underneath them. The seven 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 this project

The brain is a muscle. So is the heart. So is the will.

It's a gym — so here's my case in the language of one. Three muscles, all trained, all showing up for this build.

Brain

Knowledge is a muscle, and I've put my reps in — from NASA labs, to running operations, to three years of building software systems every single day. When I read your spec I didn't just see a feature list; I saw the whole machine — where the data lives, where the pressure points are, what has to hold when a thousand people show up at once. You put together one of the best briefs I've ever been sent. It deserves a builder who trained for it.

Heart

Health and fitness mean a lot to me — they're a real part of my life, not a market vertical. I believe in what you're building: the goal, the timeline, the spec you already put together. That's exactly why my rate is competitive. Not because I lack knowledge or ability, and not because I undervalue myself — but because I believe in this project, my talents are aligned with it, and I want to be the one who builds it.

Will

Will is a muscle you practice, and mine gets trained daily — long builds finished without anyone standing over me, and years of operations before that where the deadline carried someone else's livelihood. A fixed February date doesn't scare me. It's the kind of finish line I train for.

03 What you're hiring

Not just a front-end or back-end developer — a full-stack builder with years of management, communication, and operations behind the code.

With me you aren't hiring labour by the ticket. I read a spec for its contradictions before they become change requests. I write the process documentation as the system takes shape, not after. And I'll tell you when something in the brief won't work as written — before it costs you a month.

That's the operator half. The developer half means nothing gets lost in translation: the person who decides how the member cap gets enforced is the same person who builds it, tests it under load, and then explains it to you in plain language.

And I'm looking at this as the start of a relationship, not a single transaction. You have future locations. You'll have future ideas. What you get with me is stewardship — a full package for growth, and a vendor you can call on at any point. That's exactly why this first build gets my full attention.

04 Live work · open any of these in a browser

Every one of these is a business operating system

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.

Backend + business rules

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.

Operations dashboard

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.

User dashboard / portal

The customer-facing account: bookings, history, documents, payments, support threads. Your member dashboard is this layer.

Multi-tenant capability

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.

Also built, not always a public URL

Systems where the underlying engineering problem is the same as yours, even without a live link to click.

OMNIONEA real-time platform built for continuous high-volume ingestion — throughput, queueing, and state that has to stay correct under sustained concurrent load. The nearest thing I have built to your capacity-cap problem.
Silk RouteA wholesale trade platform with a founder sourcing internationally — inventory, cross-border logistics, and a catalogue that had to stay accurate while the business moved under it.
Lead intelligence pipelineMulti-source ingestion with deduplication, enrichment, and confidence scoring — identity resolution across records that disagree, the same shape as your HubSpot trial-abuse dedup.
Jewelry Operating SystemTrend ingestion through generative design into CAD and manufacturing output. Evidence I build full pipelines end to end, not just an interface over someone else's system.

05 The build, in plain terms

You're not buying a gym app. You're buying the platform that runs the gym.

Reading your brief carefully, the member app is actually the smallest piece — the window. 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.

What you're actually buying — five things, not one

The member appWhat members touch — booking, paying, opening the door, referring friends. Important, and honestly the most standard part of the whole build.
The admin portalYour brief says "full account management," and that's not a login page — it's an internal operating system for the business: members, capacity, tickets, waitlists, campaigns, analytics, all in a browser.
The backend platformWhere almost all the work is. One member upgrades their tier and eight things have to happen in order — validate, GymMaster, Stripe, HubSpot, app, notification, log, dashboard. The backend conducts that orchestra every time, for every event.
The integrationsYou already own GymMaster, HubSpot, and Stripe, and they're not changing — so I build around them, never duplicate them. Realistically this is a third or more of the total engineering effort, and it's work I do constantly.
The rules engineCan this member book? Transfer? Use a trial? Open the door? Every one of those answers is custom business logic — and every one ships as a setting you can change, not code you have to pay to rewrite.

The roadmap

Month 1 · FoundationsOne home for all your information — members, memberships, payments, bookings — wired to GymMaster, HubSpot, and Stripe test environments. 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. You'll see: a member sign up, pay, and appear 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, not hardcoded, 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. You'll see: a door opening from the app, and 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.

The technical points, in plain language

The two member caps — 1,000 founding, 1,700 ongoing

What you asked forHard caps that can't oversell, even in a launch rush.

What it really meansWhen the presale opens, hundreds of people will hit "join" in the same moment. If the app only checks "is there room?" on the screen, two people can both see yes — and you've sold slot 1,001. The only referee that can't be fooled is the database itself: it processes one claim at a time, holds a slot while someone finishes checkout, and quietly releases it if they walk away. That's exactly where I'll enforce it — and the cap numbers live as settings you can change, not code, because you told me this engine runs again at the next site.

Peer-to-peer membership transfer

What you asked forA member hands their membership to someone else, cleanly.

What it really meansThis is a baton pass, and the whole job is defining the rules of the pass: who's allowed to give, who's allowed to receive, the exact moment the handoff becomes final, and what happens if either person drops it mid-pass. Every step gets written down as it happens — a full audit trail — and the member count stays exact the entire way through, so a transfer never opens or eats a slot by accident. The incoming member sets up their own payment method, which was your own recommendation and the right one: it keeps billing history clean.

Door access — tap to open, QR as backup

What you asked forPhone opens the door; QR covers the gaps.

What it really meansThe main path is simple: phone near the door, member taps, the app tells GymMaster's door system to open. That path needs internet at the door — which is exactly why your rotating QR fallback is the right call for dead spots. The part I'll pressure-test hardest is the handoff between the two, because 5am at a locked door is the moment a member judges the entire app.

One codebase or two — how the apps get built

What you asked forMy recommendation on native vs. cross-platform — you left it open.

What it really meansMy recommendation is cross-platform: one shared codebase compiled for both stores — against a fixed February date it means the business logic gets built once, not twice. The specific framework gets locked per spec, in week one, with you, in writing. And if any single piece — like the Bluetooth behaviour at the door — turns out to need native code, that piece goes native. The build serves the spec, not a framework preference.

Where everything lives — hosting and data

What you asked forAustralian hosting, and my provider recommendation.

What it really meansYour members' health waivers and personal data stay on Australian soil, full stop — and the door responds fast because the server is close. Test and live environments stay fully separated, each with their own GymMaster, HubSpot, and Stripe configurations, exactly as your brief lays out. My recommendation is AWS's Sydney region — the most mature Australian region, with a managed database that gives the row-level locking your caps depend on as a first-class feature, and queueing services that fit the GymMaster, HubSpot, and Stripe webhook traffic naturally.

The independent security review

What you asked forA security and concurrency review of the caps, payments, and transfer flow.

What it really meansBefore launch, someone who isn't me tries to break the most sensitive parts — the caps under load, the money, the transfer. You asked for this in the brief and it's the right instinct. I already have my reviewer in mind and will name them on request. They stay external, because a builder marking their own homework isn't a review.

Every section of your brief, in plain English

Your specification runs seventeen sections. Here is what each one means in practice, and when you get it.

1ArchitectureSetup

Your three systems stay exactly where they are — I don't replace anything you already pay for. I build the member app, the dashboards, and the layer underneath that keeps all three talking to each other. Your Figma designs get built as drawn.

2GymMasterMonths 1 & 4

Everything that happens to a membership — joining, upgrading, downgrading, pausing, cancelling — flows both ways between the app and GymMaster, so the two never disagree. The app opens your doors through GymMaster's own door system, with the QR code as backup when the internet at the door is patchy.

3HubSpotMonths 1–2

HubSpot becomes your memory. It holds the waitlist, tracks where every lead has got to, and remembers who has already used a free trial — so nobody gets a second one by signing up with a new email address.

4StripeMonth 2

All the money. Weekly memberships across your three tiers, the $34.95 joining fee, personal-training add-ons, casual packs, Apple Pay and Google Pay. If a card fails it retries properly, membership status updates the instant anything changes, and nobody ever gets charged twice.

5Presales campaignMonth 3

Your launch day. Everyone on the waitlist gets their own single-use code at the same moment, and exactly 1,000 memberships get sold — not 1,001, no matter how many people press buy in the same second. Anyone who misses out is automatically moved onto the 15%-off-for-life offer. Every number here is a setting, so your next location runs the same launch without a rebuild.

6Ongoing capacityMonth 3

The gym never sells past 1,700 members. The moment someone cancels, that spot opens for the next person in line. When you're full, people are stopped before the payment screen and put on a waitlist instead of being charged. Staff and instructors don't count toward the number.

7Booking windowsMonth 4

Full Pass members book the sauna and cold plunge 7 days ahead. Gym-only and BJJ/MMA members get 3 days. Casual pack holders get 24 hours. You can change any of those three numbers yourself, whenever you want, without paying a developer to touch code.

8Free trialMonth 2

One free week per person, ever — not per email address. It's checked against HubSpot's record, so a new email doesn't earn someone a second go. At 12:01am on day 8 it rolls into paid automatically. If someone's already had one, they're sent to a screen telling them to contact your team. You can switch trials off entirely with a toggle.

9ReferralsMonth 4

Every member gets their own invite link. When someone they invited joins and actually pays, the member gets a free month applied automatically, and their name lands on the new member's GymMaster profile so you can see who brought who.

10FeedbackMonth 5

A real conversation, not a contact form. A member reports a problem and attaches a photo; it reaches your team with their account details attached. When you reply, the answer arrives back in their app — and the whole thread is kept.

11Google reviewsMonth 4

Members rate you from inside the app. Four or five stars and they automatically get 7 days free on their next bill, and the rating goes out to your Google Business listing.

12Membership transferMonth 5

A member hands their membership to someone else. I check they're allowed to, confirm who's receiving it, verify that person's identity, and set up their own payment method. In GymMaster it moves as a profile transfer rather than a cancellation and a fresh signup, so membership history stays intact. Your member count stays exact the whole way through, both people get told at every step, and there's a permanent record of what happened.

13Member dashboardMonth 5

Members see how long they've been with you, how many times they've checked in, and how many friends they've successfully brought in. New members get a walkthrough the first time they log in — one you can edit yourself and reuse at the next location. Notifications for class reminders, billing, spots opening up, and account changes.

14Apps & web portalMonths 5–6

iPhone and Android apps built from your Figma files, plus a browser dashboard where members manage everything except opening the door — that stays phone-only, deliberately. Both apps submitted to the App Store and Play Store with time built in for review and, if needed, resubmission.

15The engineering standardsThroughout

A separate practice environment and a live one, so nothing ever gets tested on real members or real cards. Hosted in Australia, as you require. Someone other than me security-reviews the money, the door, and the two caps. Everything encrypted, everything tested — including a simulated launch-day rush before your real one.

16The timelineConfirmed

Yes. Mid-August start, delivered by end of February, with store review time already inside the schedule rather than hoped for at the end.

17What you asked forThis document

All five answers are here: how I'd build the apps and why, where it's hosted and why, the total cost, what I'm assuming from your side, and confirmation the date is achievable.

06 Where SSTIEM sits

Not an agency. Not a freelancer.

The agency route

AUD $150–330 an hour

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.

SSTIEM

One person in charge

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.

The marketplace route

Run and gun

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.

07 Compensation

Total estimated cost: US$42,000.

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.

Where the thousand hours go

Foundations + integrations~170 hours — the data model, GymMaster / HubSpot / Stripe wiring, and separated test and live environments
Billing + membership~150 hours — weekly billing across tiers, the access pass, add-ons and casual packs, trial logic, failed-payment handling
The capacity engine~160 hours — presale tokens, both caps enforced at the database, the fallback offer, and simulated launch-rush testing
Doors, bookings, referrals~150 hours — tap-to-open, the QR fallback, tiered booking windows, referral and review rewards
Apps, portal, transfer~220 hours — the member app from your Figma, the admin portal, the membership-transfer workflow, the feedback loop
Hardening + launch~150 hours — security review, load testing, store submission with review buffer, documentation, handoff

Roughly 1,000 hours at an effective US$42 an hour. 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.

The structure $7,000 / month × 6

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. We can also set payment benchmarks together if that suits you better.

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 team, that's a different scope and a fair conversation — happy to have it.

Not scoped in

Tooling, VPS and hosting, and third-party subscriptions — passed through at cost once the stack is locked, agreed before anything is spent.

Also separate

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.

After launch

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. What modern tooling made faster is the typing — I pass that saving to you. The judgment, the architecture, and the accountability stay senior, and stay mine.

08 Questions — yours and mine

The timeline works. A few things to settle together.

Answering yours

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$42,000 — roughly 1,000 hours across six months, billed at US$7,000 a month, with tooling, hosting, and store costs passed through at cost, per section 07.

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 — yours.

Asking mine

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.

The Apple Developer account — published under your account or mine? I'd recommend yours, so the business owns its own listing; I'll run it either way.

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?

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.

Thomas Tyler Hill · SSTIEM
Bali, Indonesia · GMT+8 · sstiem.pro@gmail.com