Services
We take a product from an idea to a maintained release in the app stores. The areas below describe what that involves in practice. Most projects need most of them; none of them are outsourced.
Defining what the product is before deciding what it looks like: the problem it addresses, the people it is for, the behaviours it should encourage, and the features it will deliberately refuse to add.
Deliverables include user flows, interface design for every state a screen can be in, and a written record of the decisions behind them.
Native applications for iOS and Android, written in Swift and Kotlin, built against current platform frameworks and tested on the range of devices and OS versions a real audience actually runs.
Accessibility, dynamic type sizes, dark mode, and reduced-motion support are treated as part of the build rather than as a later pass.
The APIs, storage, and authentication a client application depends on, sized to the product rather than to a hypothetical future scale.
Data is encrypted in transit and at rest, access to production is limited and reviewed, and backups are tested rather than assumed.
App Store Connect and Google Play Console setup, build signing, staged rollouts, beta distribution, store metadata, screenshots, and the review correspondence that follows a submission.
Crash reporting and release monitoring are configured before the first public build, not after the first bad one.
Data inventories, privacy policy drafting, App Privacy declarations that match what the code actually collects, age rating, in-app account deletion, and user reporting and blocking where the product needs them.
We keep the declared behaviour and the real behaviour in sync, because a mismatch between them is both a compliance problem and an honesty problem.
Annual OS migrations, dependency updates, deprecation fixes, performance work, and the steady stream of small corrections that decide whether an application is still usable three years after launch.
Support correspondence is answered by the people who wrote the code, which tends to shorten the distance between a report and a fix.
Process
Five stages, in order. The boundaries between them are real: we do not start building while the shape of the product is still moving, and we do not submit for review while known defects are open.
A short written definition of the product: who it serves, what it must do, what it will not do, and how we will know it worked. Everything downstream is measured against this document.
Flows and interface design for the full product, including empty, loading, error, and offline states. Reviewed on real devices before any of it is committed to code.
Implementation in short increments, each ending in an installable build. Backend and client are developed together so integration problems surface early rather than at the end.
Beta distribution, store metadata and privacy declarations, submission, and the response to any review feedback. Rollout is staged so a bad build reaches few people rather than all of them.
Monitoring, support correspondence, fixes, and platform migrations, on an ongoing basis for as long as the product is published.
A single point of contact, written decisions, and no work in progress announced publicly before it is ready to be used.
Tools
A short list, kept short on purpose. Every dependency is a future migration, so each one has to earn its place.
Swift, SwiftUI and UIKit, Xcode · Kotlin, Jetpack Compose, Android Studio · TestFlight, App Store Connect, Google Play Console.
Managed cloud hosting in the United States, relational storage, object storage for media, transactional email delivery.
Version control with reviewed changes, automated builds, crash and error reporting, uptime monitoring.
Describe what you are trying to build and what is currently in your way. If it is a fit we will say so, and if it is not we will say that too — you will get a straight answer either way.