One pipeline, every product.
The studio model only pays off if the second product costs less than the first. These are the six stages every product goes through, and the parts we build once and carry forward.
Selection
Most ideas die here, on purpose.
A concept has to clear four tests before it becomes a product: the problem is acute and has a deadline attached, the output is a visible artifact the user can judge without trusting us, someone in that situation is already spending money nearby, and we already own most of the machinery. Failing any one of them is disqualifying.
- Problem acuteness
- Visible artifact
- Existing spend
- Infrastructure overlap
The vision and video layer
Pose estimation on the user's own footage.
A short clip comes off a phone camera and comes back with tracked joints drawn onto it. Decode, estimate per frame, render, re-encode, deliver, all inside a window short enough that someone holding a phone does not give up. The same service serves both sports products, so each one's traffic keeps it warm for the other.
- Frame-accurate overlay
- Shared render service
- Retention policy
- Cold-start headroom
The language layer
Raw model output is not a product.
Analysis is converted into a fixed contract: what is working, the main issues, the fix, and a suggested drill. Both sides enforce that shape, so the app never renders an empty panel because a model got creative with its formatting. Model calls walk a chain and report every failure in the chain, not just the last one.
- Structured contract
- Model fallback chain
- Plain-language faults
- No numeric scores
The commercial rails
The least interesting code in the company.
Authentication, subscriptions, receipt validation, and a webhook that reconciles store events against rows we control, so whether a person paid is answerable from our own database. Identical across products. This is where the seams are, and seams are where consumer apps actually break.
- Subscription billing
- Webhook reconciliation
- Identity aliasing
- Attribution
Store presence
For most people, the listing is the product.
Screenshots have to argue rather than document, and the first two frames have to answer the objection that stops the install. This stage gates on real footage of real usage, which is a dependency no amount of engineering removes. We would rather hold a finished build than launch onto a listing that does not convert.
- Screenshot argument
- First-two-frames rule
- Listing copy audit
- Review exposure
Operate, indefinitely
Nothing here is disposable.
Product support is answered by the people who wrote the code. Every app stays current with each OS release for as long as it is listed. A studio that ships a fourth product while the first is broken does not have a portfolio, it has a graveyard with a marketing site.
- Founder-answered support
- OS release upkeep
- Incident triage
- No abandoned listings
What we do not do.
- Client work
- No contracts, no retainers, no white-label builds. Every product is one we own outright.
- Training our own foundation models
- It would be a worse product and a worse business. We use what exists and own the seams around it.
- Shipping scores instead of answers
- A number out of ten is easy to build and impossible to act on. We name the fault and give the fix.
- Launching onto footage we are not proud of
- A finished build behind a weak listing gets no downloads and produces no data worth reading.
See what it produced.
The process is only worth describing because of what came out of it. Three products, all of them live on the App Store today.