Studio19 captures every swing from two fixed camera angles and locks it to launch-monitor data. The cause is as visible as the result — and the lesson reaches your player's phone before they leave the bay.
A launch monitor tells you the ball started 3° right and spun 2,400rpm. It won't tell you the player's trail hip fired early. A phone on a tripod shows you the hip — but at a different angle, distance and height than last week, so you can't measure what changed.
Coaches end up running two tools that don't talk to each other, and doing the hardest part in their head.
Result without cause
What the numbers won't show you
Dispersion, spin, carry — the evidence of a swing, with no account of what produced it.
Cause without consistency
What handheld video can't measure
A new angle every session, so nothing is comparable and nothing is trackable.
The capture
One swing. Three streams. Locked together.
Every shot is captured as a stereo-19 shot — two camera angles and the radar, time-aligned to the same swing event.
Camera positions are fixed and identical in every bay. That's the part that makes everything downstream possible.
Angle 01
Down-the-line
Plane, posture, swing path. The angle that shows where the club is working.
Angle 02
Face-on
Rotation, weight shift, sequencing. The angle that shows how the body delivers it.
Radar
Launch-monitor data
Club and ball through impact, from FlightScope. Club speed, path, face, spin, dispersion.
The idea
Coaching happens before impact.
Studio19 organises everything around one distinction — not video versus radar, but time relative to impact.
Both video and radar contribute to both sides. Every screen answers one of two questions — what did the body and club do? or what did that produce? — and the good ones link the two.
Launch angleSpin rateBall flightCarry & totalDispersionRoll out
The workflow
Finish and ship. That's the whole export step.
Scrub to the frames that matter. Lock them. Draw on them — lines, circles, boxes. Talk over each one. Add the notes and the score.
Then hit Finish & Ship. Your player's phone receives a guided film: their swing plays, pauses on each coached frame with your lines drawn on it and your voice explaining it, then rolls on. No editing, no exporting, no sending files, no explaining it again over WhatsApp.
Clip the framesScrub and lock what matters.
Draw and talkLines and voice, per frame.
Finish & ShipOne action.
It's on their phoneBefore they leave the bay.
What lands on the player's phone
Why fixed capture matters
A folder of videos, or a record of a player's game.
Because the cameras never move, a frame from today lines up against a frame from last season. Same position, same perspective, measurable difference. Across sessions, across clubs, and across coaches at the same facility.
Handheld video changes angle, distance and height every time — so part of the difference you see is just the camera.
Per-club trends across sessionsEvery session, kept
The player app
Your coaching doesn't stop at the door.
Players get their own app — not a stripped-back viewer, a reason to come back between sessions.
A coaching inboxNew lessons appear the moment you publish them.
Every session, every shotRated, searchable, both angles and the numbers.
Guided lessonsThe swing, the coach's marks, the coach's voice.
HomeworkDrills the coach assigns, with sets tracked.
ProgressPer-club trends across sessions, not vibes.
A private journalThe player's own notes on their rounds.
BookingThe next session, from the same app.
Coach-linked by designPlayers you invite stay linked to you — the coaching relationship is yours.
InboxBag & journal
Who it's for
The independent coach
Stop exporting clips and typing explanations. Capture, coach, ship — and give your players something worth paying for between lessons.
The facility or academy
Every bay captures identically, so every coach's work is comparable and the facility's data compounds instead of scattering across phones.
Corporate Identity
S19Labs design system
The visual language of the Studio19 players app, documented as the corporate identity. Ported verbatim from lib/theme/tokens.dart — itself a port of the iPad app's DesignSystem/Theme.swift.
Dark-first · near-black neutral baseOne accent, used sparingly
The mark
App icon
The Studio19 script wordmark, white, on the neutral base with a turquoise bloom behind it. Shipped on iOS and Android; also this site's favicon.
Squircle radius scales with the mark — l (20px) around 72–82px, s (6px) at favicon sizes. Never outline it, never recolour it, never set it on a mid-tone.
Wordmark
The same script as pure vector — studio19-logo.svg, white paths, no background. Use this wherever the mark must sit on an existing surface or scale past icon sizes.
White only. On light surfaces the fill must be overridden to the base colour, never tinted with the accent.
Naming, unresolved. The mark reads Studio19 — the product —
while this site and the top bar say S19Labs — the company. They are
currently used side by side. Worth deciding whether the public site leads with the company or the
product before this hardens into two competing identities.
Colour
Four families. Surfaces layer; ink is white at declining opacity; the accent is brand-only; semantic colours mean something and are never decorative.
Surfaces
bg
#0a0a0b
Page base
surface
#161618
Cards
surfaceElev
#202023
Raised / inputs
surfaceElev2
#2a2a2e
Highest layer
base
#0a0a0c
Liquid-glass base — carries no colour
bloom
#22c8d2
Ambient light only, never a fill
Ink
ink
#ffffff
Primary
textPrimary
#f2f2f7
Body copy
ink2
EBEBF5 · 60%
Secondary
ink3
EBEBF5 · 30%
Tertiary / hints
ink4
EBEBF5 · 18%
Disabled
Brand accent
accent
#00da9b
Brand + ONE primary action per view
accentPressed
#00b886
Pressed state
accentSoft
accent · 16%
Tonal fill
accentGlow
accent · 36%
Blur/shadow ONLY — never a fill
featureGold
#ffc23d
Feature requests
The one rule that matters. The accent #00DA9B is brand identity, not "good". The semantic positive green is #30D158 — a different colour. Using the accent to mean "this value is healthy" is the single most common way this system gets broken.
Semantic
positive
#30d158
Good data
caution
#ff9f0a
Warning
negative
#ff453a
Error / duff
info
#0a84ff
Informational
premium
#bf5af2
Premium
Rating ramp
Monotonic green→red for 0–100 shot ratings. In the app this collapses to a three-band traffic light: green ≥ 70, amber 30–69, red < 30.
excellent
#30d158
good
#8ad13f
acceptable
#ffd60a
poor
#ff9f0a
bad
#ff453a
Typography
System sans throughout. Tight negative tracking on display sizes, neutral below. Every row below is set in the style it names.
displayStudio1956 / 700 / 1.04 / −2%
h1Session review40 / 700 / 1.08 / −2%
h2Your progress28 / 600 / 1.18 / −2%
h3Driver · carry20 / 600 / 1.28
h4Shot 14 of 4016 / 600 / 1.32
bodyYour coach marked this swing for review.15 / 400 / 1.55
Three curves, three durations. Hover a track to run it.
easeOut
.16, 1, .3, 1 — entrances
easeInOut
.65, 0, .35, 1 — moves
easeCinema
.22, 1, .36, 1 — video / hero
fast180ms
medium320ms
slow640ms
Usage
One accent action per view. If two things are turquoise, neither reads as primary.
Layer surfaces upward — bg → surface → elev → elev2. Depth comes from layering, not from borders.
Hairlines at 8% white. Visible structure, invisible lines.
Mono for numbers and identifiers only — carry, smash, ticket ids.
Never use the brand accent for "good". That's positive #30D158.
Never fill with accentGlow — it is a shadow colour.
Never tint the base surface turquoise. All warmth is light from the bloom; the surface stays neutral.
No pure-white body text at small sizes — textPrimary #F2F2F7 and below.
Known drift. Mission Control's own chrome predates this system and uses
#06D6A0 as its accent, not the brand
#00DA9B. The two are close enough to look like a rendering
difference and far enough apart to be wrong. Unifying it means restyling the dashboard,
so it is recorded here rather than silently patched.
The P4 Problem · an S19Labs challenge
Measure the swing where the camera goes blind.
A golf swing hides its own mechanics. Build something that measures them anyway — on one phone, in one swing, with no motion-capture rig and no setup ritual. Any method you like.
Anyone 18 or older. Built for engineering, computer science and sports science students, and open to anyone outside a university too. Teams may not be larger than five participants — that cap applies at registration and at the in-person build. One team per person. Employees of S19Labs, the judges, and their immediate families cannot enter.
The three approaches
Every entry takes one of three routes: pure pose detection, marker-based object detection, or IMU sensors on the body. You state which one in your proposal — there is nothing to declare at registration, and nothing to commit to before you have thought about it.
Finalists are chosen per approach, three teams each, so you are judged against the teams who took the same route rather than against all entrants at once. Winners are chosen the same way, with one overall winner across all three.
One approach per proposal. If your design genuinely spans two, say so and name the one it leads with — we would rather read that than guess which pile it belongs in.
IP and licensing
You keep copyright in your submission. You keep it in your portfolio, you can keep developing it after the competition, and you can build a company on it. To enter, you grant EPSza a non-exclusive licence to build, run and evaluate your entry for judging.
Accepting a prize is different. If your entry is awarded a prize and you accept it, copyright in that submission is assigned to EPSza, and you warrant that you are entitled to assign it. Prize money is the consideration for that transfer. You may decline a prize and keep your work — the ranking and your published scorecard stand either way.
If you do not win, nothing changes. Non-winning entrants keep their submission outright, and are free to open-source it, publish on it, or commercialise it themselves.
Read this before you register if you are a student. Most South African universities can claim rights in student work, particularly where it touches coursework, a supervised project, or campus resources. If your institution owns your work then you cannot assign it — which means you may be unable to accept a prize. Talk to your supervisor and your technology transfer office before you enter, not in October. We are happy to speak to your institution directly, and we would rather resolve it up front than take a prize back.
What you may build on
There are no AI restrictions. Use whatever coding assistants, models and tooling you like, at whatever depth you like. There is no disclosure requirement and no penalty attached to it — we assume you are using them.
Dependency licences are a different question, and they still bind. Licences change, the repo carries the authoritative list, and you must verify anything you use yourself. Pretrained weights often carry terms separate from the code that trained them.
Dependency
Status
Note
MediaPipe / BlazePose
clear
Permissive. The baseline uses it.
MoveNet / TF Hub pose
clear
Permissive. Check each specific model card.
Ultralytics YOLO
blocked
AGPL-3.0. Commercially unusable for us without a paid licence. Do not build on it.
OpenPose
blocked
Non-commercial academic licence only.
SMPL / SMPL-X body models
check first
The approach is welcome; the model files carry their own commercial terms. Ask before you commit weeks to it.
Anything else
declare it
Open an issue and we rule on it publicly within two working days, so every team gets the same answer.
Building on a blocked dependency does not lose you points — it removes you from the competition, because we cannot ship the result. Ask early.
Data and POPIA
Any footage we release to you is licensed for this competition only: no redistribution, no publication of frames containing an identifiable person, and deletion on request. Every golfer we film has given written, informed, revocable consent, and the set is handled under POPIA. The full data agreement is in the repo and you accept it at registration.
If you collect your own footage — at the proposal stage or the build — get written consent from anyone you film and handle their data under POPIA. Declare any external or synthetic data you use.
What we release, and at which stage, is still being decided. The data agreement in the repo is the binding version; this page follows it.
What you submit
Two different things, at two different stages.
Stage 1 · the proposal
A written reportHow you would solve the problem, and why your design should work. Against a proposal template we publish before the deadline.
The approach you are takingPose detection, marker-based detection, or body-worn IMUs. Named explicitly — it decides which pool you are judged in.
Your teamUp to five people, declared at registration.
A public repositorySet up per the readme conventions. Any exploratory work belongs there, in the open, as you do it.
Proposal-stage hardware is at your own expense, and nothing requires you to buy any. A proposal is a written argument — a working prototype is neither expected nor a prerequisite.
Stage 3 · the build
The system you proposedBuilt at our office, on hardware we supply, over the event.
Everything on the repositoryAll work transparent and committed as you go. A single squashed commit at the end is not accepted — we read the history.
Third-party asset declarationEvery model, dataset and library, with its licence and version. AI assistants need no declaration; dependencies do.
The proposal template and the full Stage 3 deliverable list are still being written. Both land in the repo before Stage 1 opens, and this page is updated when they do.
How it is judged
Stage 1 is judged on the proposal alone — the strength of the design, the reasoning behind it, and whether it is buildable in the time the in-person event gives you. Three teams per approach go through.
Stage 3 is judged on what you actually build. A winner is chosen for each of the three approaches, and an overall winner across all three.
Detailed criteria and weightings are not set yet. They are published with the proposal template, before Stage 1 opens — not invented after submissions are in.
The four stages
Every date is TBC. Times will be SAST.
Stage 1Proposals in · TBCRegistered teams submit a report proposing how they would solve it, and which approach they are taking. This is the preliminary filter — nothing is built yet.
Stage 2Finalists announced · TBCThree teams per approach are invited to the in-person build, from the proposals alone. Invitations are confirmed by the team.
Stage 3In-person hackathon · TBCFinalists build the system they proposed, at our office, on hardware we supply. This is the event the proposal earned you a seat at.
Stage 4Winners · TBCOne winner per approach, plus an overall winner across all three.
FAQ
Do I need to know anything about golf?
No. The repo includes a short primer on the P-System and the measurements. A biomechanist is available in the Q&A channel throughout.
Do I pick my approach when I register?
No. You name it in your proposal. Registration captures your team and nothing about your design, so there is nothing to commit to before you have thought about it.
Can I submit proposals for more than one approach?
One proposal per team, naming one approach — finalist places are allocated per approach, so a team cannot occupy two pools at once. If your design genuinely spans two, name the one it leads with and say so in the report.
Are there really no AI restrictions?
None. Use whatever assistants and models you like, as deeply as you like, with no disclosure requirement and no penalty. Dependency licences are a separate matter and still apply — see what you may build on.
Do I need to buy hardware to enter?
No. Stage 1 is a written proposal; anything you choose to buy or borrow to test an idea first is at your own expense, and none of it is required. All hardware for the in-person build is supplied by us.
What happens at the in-person hackathon?
Finalists build the system they proposed, at our office, on our hardware. The proposal earns the seat; the build is what is actually judged for the win.
Can I collect my own data?
Yes, and it is a good idea. Get written consent from anyone you film and handle their data under POPIA. Declare any external or synthetic data. Public datasets are fine subject to their own licences.
Does my work have to be public while I am doing it?
Yes. All work is done transparently on the GitHub repository, following the conventions in its readme. We read commit history — visible progress is part of it, not a formality at the end.
What happens if I win?
Accepting a prize assigns copyright in that submission to EPSza — see IP and licensing. You may decline the prize and keep your work; the result stands either way.
Where do I ask questions?
GitHub Issues on the competition repo. Everything is answered in public so no team gets an information advantage.
Register
Registration captures your team, your university or organisation, and acceptance of the data agreement. Your approach is not declared here — that goes in the proposal. Registering unlocks Hackathon MC, where the briefing and the supporting theory live.
live · prod
Overview
The pulse of the S19Labs player app — pulled live from the backend.
Users
—
loading…
Open bugs
—
loading…
Needs retest
—
resolved · verify
Production
checking…
studio19-coaching-api
Staging
checking…
…-api-staging
Recent reports from the app
loading…
Missions
The build backlog — split by who owns it. Open a card for the plan; Edit to change it. Arm ⚔ to queue it for a war.
loading…
Ready for WAR
The armed queue, grouped by person. Toggle ⚔ on mission cards to arm them; each person's Declare war locks their set into a WAR-n order for Claude.
Shared headless key (studio19-public-dashboard-api-key, Secret Manager · s19labs) is not created yet — so for now, Declare war → Copy war order bundles a fresh ~1h admin token into the prompt; paste it into your own Claude session to run the war. No key needed.
loading…
War room
Team Performance
Who's carrying what — live from the missions board, with a git-activity snapshot.
loading…
Ideas
The idea inbox, by person. Capture loosely, then promote the good ones into missions.
loading…
Planning
Market landscape, competitors, and opportunities. Edited in epsza.S19Labs.website — public/data/planning.json.
loading…
Research
Our internal R&D library for The P4 Problem — marker-based motion capture theory, competitor landscape, and how we're approaching our own entry. Full write-up and sources live in docs/marker-based-motion-capture-research.md, this repo.
How this research evolved
Started asAn internal draft on building a marker-based golf mocap pipeline, written before the brief existed.
CorrectedA dead OpenCV citation, stray AI-generation artifacts, and an uncredited Swing Catalyst mischaracterisation in the original draft.
Reframed once"Markerless model" loosened to "any approach" — then the brief itself locked it to "no markers on the body," which this now follows.
Held upThe decision not to instrument the club for ground truth held — the brief's own output contract never asks for club position either.
Competitor landscape
GEARS
Marker-based optical
8 cameras at 360fps, 34 3D markers across golfer and club. Vendor-claimed sub-0.2mm accuracy. Used by PGA/LPGA tour players and club fitters — the closest real-world precedent to our own reference rig concept.
K-Vest
Wearable IMU
Not camera-based at all — wireless sensors at multiple body points, each computing 3 degrees of freedom. Integrated into the TPI-3D software platform.
Swing Catalyst
Markerless
Cameras plus force plates plus AI pose estimation — explicitly markerless, despite being filed under "competitor research" in the original internal doc without that distinction called out.
Our own entry — starting points
Division A
Off-the-shelf pose backbone plus a sequence-level layer is the realistic starting point — nobody trains a better backbone in eight weeks. The differentiator is likely kinematic constraints and a learned motion prior specifically tuned around P4, rather than a from-scratch detector.
Division B
Lead wrist IMU for wrist extension, pocket phone for pelvis rotation/sway, microphone for impact anchoring — fused around the acoustic impact event rather than device clocks. Worth prototyping the sync approach before the modelling, since a fusion pipeline is only as good as its alignment.
Players App
Redesign roadmap — click a status chip to cycle To do → Doing → Done. Updates live for everyone.
—
loading…
loading…
Play Store
Google Play publishing checklist — click a status chip to cycle, assign an owner, add deliverables.
—
loading…
loading…
App Store
Apple App Store publishing checklist — click a status chip to cycle, assign an owner, add deliverables.
—
loading…
loading…
Environments
Watch prod and staging — health checked live.
Production
checking…
Servicestudio19-coaching-api
Regionafrica-south1
AuthFirebase · s19labs
Health—
Staging
checking…
Service…-api-staging
Regionafrica-south1
AuthFirebase · s19labs (shared)
Health—
Deploy
Publish this dashboard to Firebase Hosting.
Deploy this dashboard
Publish epsza.S19Labs.website to s19labs.web.app
Runs the deploy-hosting GitHub Action (manual trigger — no secrets in the browser). Or locally, from the website repo root: firebase deploy --only hosting.
Sideload builds are no longer served from this dashboard. Ship releases through the store pipelines, and see PROD-PUSH-CHECKLIST.md in the players repo for the push runbook.
Users & coaches
Everyone in the player app, pulled live. Tap a person to suspend or remove them.
loading…
Bug board
Live from the in-app ladybug. Drag a card or open it to move it through the loop — fire it off, then verify the fix.
Open
—
In progress
—
Needs retest
—
Closed
—
Total
—
Security
Access, posture, and the audit trail of admin actions.
Posture
Admin access
Grant via node scripts/set-admin.js <email>
Session
Settings
Console configuration.
Projects19labs · africa-south1
Mission Control hosts19labs.web.app
Prod API—
Staging API—
Connected reposplayers · service
Mission Control boardmissions · wars · to-dos (backend: .NET /api)
Skill API keystudio19-public-dashboard-api-key — not created yet
The board's own reads/writes use the signed-in admin's Firebase token. The studio19-public-dashboard-api-key secret is only needed for headless callers — the /mission skill and Claude running a war. Until it exists, use the interim token below: paste it into a Claude session so it can hit the API (Authorization: Bearer) without the shared key. (War orders embed one automatically on copy.)
A short-lived credential — for local Claude sessions only.
Sign in
Studio19 account
Mission Control requires an admin account. Signing in without it still works — you just won't see that tab.
8+ charactersUppercaseLowercaseNumber
Required to benchmark your swing against the matching tour reference. It is not used for anything else.
End User Terms of Use — S19LABS Players Coaching App
EPSza (Pty) Ltd (Reg. 2014/099878/07) — Studio19, 359 Pienaar Street, Brooklyn, Pretoria.
By creating an account you agree to the Terms of Use and confirm you have read the Privacy Policy.
Your profile and any sessions recorded by a Studio19 Certified Coach are processed as described there.
South African law applies, and the Information Officer's contact details are in the Privacy Policy.
