Native and cross-platform mobile apps, web applications, APIs and the back-end that holds them up.

We build the things we design. Mobile first, because that is where our four shipped apps live, but the same team writes the APIs and web surfaces behind them — a product is rarely just an app; it's an app talking to a server somebody has to build and keep running.

The native-versus-cross-platform decision gets made per project, not answered the same way every time. We've shipped with native Swift and Kotlin where a feature needed deep platform integration, and with React Native and Flutter where one team, one codebase and a faster path to three stores mattered more. Neither is a fallback for the other — the comparison page linked below walks through the actual trade-offs rather than a sales pitch for whichever we happen to prefer.

Shipping to Huawei AppGallery alongside the App Store and Google Play adds a real engineering wrinkle worth knowing about before it surprises you: AppGallery devices don't carry Google Mobile Services, so push notifications, maps, in-app purchases and analytics need Huawei's HMS Core instead of the Google equivalents. It's not difficult, but it's easy to miss until a build that works everywhere else fails silently on a Huawei device — we've done this integration four times.

Practically, building means source control, code review, staged environments and a release process you can repeat — not heroics the night before submission. Offline-capable data and sync are a recurring requirement rather than an edge case: Grocery List — Smart works with no connection at all and reconciles when one returns, which is a harder problem than it sounds and one we'd rather solve once, properly, than patch per project.