Prepared for one recipient. Enter your access code.
01 Live work · open any of these in a browser
Systems where the underlying engineering problem is the same as yours, even without a live link to click.
02 Background
American developer and operator, based in Bali and working GMT+8 with deliberate overlap into Australian hours. I run SSTIEM as a small, deliberately boutique development shop — not an agency, not a marketplace listing.
From 2014 to 2018 I worked in data systems and field research supporting NASA agricultural and soil programs — deploying environmental monitoring hardware and building the documentation pipelines that turned raw field telemetry into research-grade data. When a measurement has to be right, the process around it matters more than the cleverness of any one part — that's the habit this brief rewards.
Before that I directed operations for large-scale residential housing in Seattle, running logistics and vendor budgets across 300+ tenants. Since then I've started and run ventures spanning media production in Bali, an international trade platform, and service businesses in the US — hiring people, writing the protocols, and owning the outcome when something broke.
Eighteen-hour days, by choice — not a first role out of a bootcamp, but an operator building the systems he used to manage by hand. The result is the seven platforms in the strip above: every one live, every one open to inspection right now, no portfolio deck required.
I also give roughly a thousand hours a year to community teaching in sustainable agriculture and food systems. It's the same instinct that makes this brief interesting to me — systems that measurably improve how people live in their bodies and their communities.
References available on request, including client contacts who can speak to delivery and communication directly.
03 Why this project
Your spec is the most competent brief I've been sent. It already knows GymMaster is the system of record, that the cap has to hold at the transaction level and not the interface, and that a membership transfer is state design rather than a button. Reading it, I could see the architecture before I opened an editor — that's the work I actually want.
Health and fitness aren't an abstract vertical to me — they're what I organise my own life around. An app that gets someone through a door at 5am reliably, with no friction and no failed payment locking them out, is worth building carefully. I'd rather spend six months on that than on most of what software gets spent on.
Your timeline is fixed and non-negotiable. That's the part I'm best at. I've spent two years proving I finish things with no one standing over me, and longer than that running operations where the deadline was someone else's livelihood. February is a date, not a hope.
04 What you're hiring
Not a front-end developer or a back-end developer — someone who has run teams and owned outcomes, who also happens to build the whole stack.
Most quotes you'll get are for labour. This one includes oversight: I read a spec for its contradictions before they become change requests, I write process documentation as the system takes shape rather than 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 no translation layer sits between design and delivery: the person who decides the presales cap needs row-level locking is the same person who writes the migration, tests it under load, and explains the result in plain language on Friday.
I'm also treating this as the start of something, not a single transaction. You have future locations, and the presales engine is explicitly built to run again — I'd like to be the person you call for that, which is exactly why the first build gets my full attention now.
05 Where SSTIEM sits
Small on purpose — it's what lets one person hold the architecture, the code, and the conversation with you at the same time.
06 Technical position
Your spec is confirmed scope, so this isn't a restatement of it — it's my position on the two decisions you left open, plus the three calls in your existing scope worth saying out loud.
| Area | Position |
|---|---|
| Both capacity caps Presales 1,000 · ongoing 1,700 | Enforced in Postgres with row-level locking and a checkout-hold reservation, never at the application layer. Both caps and the token window ship as per-location config from day one, since this engine runs again at the next site. |
| Membership transfer | An explicit state machine with a defined irreversible point, an audit row per transition, and the capacity slot held — not released, not double-counted — for the duration. New payment method for the incoming member; it keeps billing history clean. |
| Native vs. cross-platform open decision | React Native. Every platform-specific piece here — BLE proximity, the v3 door trigger, camera capture, Apple/Google Pay via Stripe's SDKs, FCM push — has first-class support. One codebase means the business logic gets written once against a fixed February date, not twice. |
| Cloud provider open decision | AWS, ap-southeast-2 (Sydney). Meets the Australia-region requirement for the health-waiver data. RDS Postgres gives the locking primitives above as a first-class feature; SQS and EventBridge fit the GymMaster, HubSpot, and Stripe webhook traffic naturally. |
| Security review | The concurrency and payment review stays independent — I'll name the reviewer rather than mark my own homework, which is the right instinct on a system handling money and physical access. |
One flag now rather than in month three: the primary access method is internet-mediated, so door entry depends on connectivity at the door. The rotating-QR fallback is the correct answer for that — I'd pressure-test the handoff between the two early, since that's the failure people actually feel standing at the door.
07 Compensation
Roughly a thousand hours across six months — full-time, not run alongside four other clients. Priced as a monthly engagement, not a bag of line-item deliverables.
Architecture, all three integrations, the capacity engine, the transfer system, both apps, and the web dashboard — plus process documentation, weekly written reporting, and the judgement calls in between.
If you bring additional developers, or we scope in help on my side, my rate moves to reflect the split. I shift toward technical lead and architecture — still full-time, still accountable for delivery.
$30,000 at the solo rate, billed monthly. No milestone haggling, no change-request revenue model.
Tooling, VPS, and cloud costs — passed through at cost, never marked up.
Independent security review and load-testing support, quoted once named. Kept honest by being external.
Plainly: this number is competitive, on purpose. A shop in Sydney or the US quoting this scope lands somewhere very different — not because of capability, but because I'm in Bali, I want this project specifically, and I'd rather start a long relationship at a fair number than win one contract at a high one.
08 Next step
Mid-August start, end-of-February delivery, with App Store and Play review cycles absorbed in the buffer. The one thing that moves the date is a late handoff of the Figma files or the GymMaster, HubSpot, and Stripe sandbox credentials.
Thomas Tyler Hill · SSTIEM
Bali, Indonesia · GMT+8 · veeshiart@gmail.com