What you get at the end of a project
A working app is the visible part. These are the things that determine whether anyone can maintain it after we leave.
Blog
Notes from the build.
What we learned shipping our own products and clients’ — engineering decisions, testing, and how we work. Plus the archive from our consumer apps.
How we estimate, and why the number has a range
A single date is a promise about things nobody knows yet. A range is a description of what we actually know.
Dark mode is not an inverted stylesheet
Flipping the colours produces something technically dark and genuinely unpleasant. What actually has to change.
Designing for the thumb
Most sessions are one-handed, on a phone bigger than the hand holding it. Where a control sits matters as much as what it does.
Testing in-app purchases without losing your mind
The purchase flow is the least testable and most expensive path in a mobile app. How we make it boring.
How to write a bug report that gets fixed
Most reports cost an engineer twenty minutes before any code is read. Four lines fix that, and they are the same four lines every time.
Anti-cheat basics for casual games
You will not stop a determined attacker on a rooted device. You can make it not worth their time, and you can make sure they cannot cash out.
A game loop that survives contact with players
The core loop is not the mechanic. It is the reason someone opens the app tomorrow, and it is usually decided before any art exists.
Frame pacing on low-end Android
Sixty frames per second is not the goal. Consistency is. A steady thirty feels far better than a jittery fifty-five.