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.
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, accounted for
Your specification runs seventeen sections. Here is where each one lands in this build.
| Your section | How it's covered |
| 1. Architecture | Confirmed as written — GymMaster, HubSpot, and Stripe stay the engines; I build the orchestration and member-facing layer on top. Figma treated as developer-ready and honoured, not reinterpreted. |
| 2. GymMaster | Two-way lifecycle sync, weekly billing reflected not recalculated, v3 door-trigger for access, Gatekeeper for the QR fallback, and native booking surfaced with my tier validation in front of it. Month 1 and 4. |
| 3. HubSpot | Lifecycle stages, waitlist capture, and trial-abuse dedup against the CRM record — treated as your identity system, not a marketing tool. Custom Code Actions for real-time sync. Month 1–2. |
| 4. Stripe | Weekly subscriptions across all tiers, the $34.95 access pass, PT add-ons and casual packs, Apple/Google Pay, failed-payment retry, webhooks for every state change, idempotent checkout. Month 2. |
| 5. Presales engine | Uncapped waitlist, simultaneous single-use tokens, 1,000-slot cap held at the database with checkout-hold reservation, auto-invalidation, 15%-for-life fallback — shipped as per-location config for future sites. Month 3. |
| 6. Capacity management | 1,700 ceiling, real-time tracking, slot released the instant a member exits, signup blocked before payment at capacity with waitlist routing, staff and instructors excluded. Same transaction safety as §5. Month 3. |
| 7. Booking windows | 7 / 3 / 24-hour advance windows by account type for the recovery zone — all three values backend-configurable, no code change to adjust. Month 4. |
| 8. Trial logic | 7-day trial with backend on/off toggle, one per person for life, dedup against HubSpot's record rather than local data, automatic transition at 12:01am on day 8, admin intercept on duplicates. Month 2. |
| 9. Referrals | In-app portal with unique URL per member, conversion tracked on paid signup, one month free to the referrer, referring member's ID pushed to the GymMaster profile field. Month 4. |
| 10. Feedback module | Built as a ticketing system, not a contact form — media upload to object storage, flagged to management with account context, and a real reply thread back to the member with notification. Month 5. |
| 11. Google reviews | Rating captured in-app first, synced out to the Business listing, with 4- and 5-star ratings automatically applying 7 days free to the next billing cycle. Month 4. |
| 12. Membership transfer | Full state machine: eligibility, named recipient, identity verification, new payment method for the incoming member, GymMaster profile transfer rather than cancel-and-rejoin, slot held accurately throughout, defined point of no return, mid-transfer failure handling, notifications both sides, complete audit trail. Month 5. |
| 13. Dashboard & push | Live tenure, check-in totals and referral counts; a reusable backend-configurable onboarding walkthrough triggered on first login, dismissible and revisitable; FCM push for classes, billing, capacity openings, and lifecycle events. Month 5. |
| 14. Apps & web portal | iOS and Android from your Figma, plus the browser dashboard sharing one backend with full account management — gate access stays native-only. Store submission with review buffer. Months 5–6. |
| 15. Non-functional | Separated staging and production each with their own GymMaster/HubSpot/Stripe configs, Australian hosting, CI/CD, independent security and concurrency review of §5/§6/§12, unit + integration + end-to-end testing including simulated concurrent presale load, encryption in transit and at rest. Throughout, hardened in month 6. |
| 16. Timeline | Confirmed achievable. Mid-August start, delivery end of February, with store review cycles absorbed in the buffer. Section 08 names the one dependency that could move it. |
| 17. What you asked for | Tech approach and cloud provider recommended with reasoning above; total cost in section 07; assumptions and dependencies in sections 07 and 08; timeline confirmed. All five answered. |
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.