How I work
A small studio can afford to be careful.
No sprints for the sake of sprints, no feature lists for the sake of a roadmap. Just a way of working that consistently turns a real problem into a reliable app.
-
Start from a concrete problem
Every Loopz app begins with a moment I've experienced or watched closely: a parent typing scores into a group chat, a rehab plan quietly losing to a phone. If I can't describe the problem in one sentence, I don't build the app.
-
Understand the real usage situation
A sideline is cold, wet and one-handed. A rehab session competes with every notification on the phone. The situation—not a persona document—decides what the app must do and, just as importantly, what it can skip.
-
Build a focused first version
The first version does one job end to end. Native for iPhone, no filler screens, no settings for problems nobody has yet.
-
Test behaviour and reliability
My background is QA engineering, and it shows here: what happens when the connection drops mid-match, when a session is interrupted, when someone taps the wrong thing at the worst time. Edge cases are part of the product, not an afterthought.
-
Improve based on evidence
Support messages, real-world behaviour and careful iteration decide what changes. Features earn their place; they don't get it for free.
-
Treat privacy and accessibility as product work
Data stays on the device unless sharing is the point. Labels, contrast and reduced motion get tested like any other behaviour. These aren't compliance chores—they're part of what "working properly" means.
Sound like your kind of builder?
Take a look at the apps, or just say hello.