Solutions
One app for Android and iOS, not two parallel builds.
Cross-platform development with Flutter: a single codebase, two stores, and the same team accountable for both.
When it makes sense
Signs the browser is no longer enough.
An app is not justified by owning one. It is justified when something like this is true:
- The work happens away from a desk: in the field, on a sales floor, on the move.
- You need something the browser will not give you: notifications, camera, location, offline use.
- A web platform already exists and people open it from a phone every day.
- There are two apps — one per operating system — that have been drifting apart for months.
- The current app stopped receiving updates and the store has started warning about it.
- A tool has to reach the internal team without being published to the public.
What we build
Kinds of app.
Field operations
Capture, photo evidence, signatures and statuses, syncing when the signal comes back. Work does not stop because the connection dropped.
Customer portal on the phone
Status, documents, notices and requests. The same information as the web portal, on the screen people actually look at.
Internal tools
Apps for your own team, distributed through a private channel or through the stores with restricted access.
Content and learning
Courses, assessments, progress tracking, and downloads for use without a connection.
Second screen for a platform
When the system already exists, the app consumes the same API and does not duplicate business rules.
Rescuing an existing app
Assessment of an inherited codebase, dependency updates, and compliance with what the stores require today.
How it is built
One codebase, with native decisions where they actually matter.
One codebase, with native decisions where they actually matter.
Flutter is not a fashion choice: two teams building the same app produce two different apps, and the difference always shows up in the features that get tested least. What is genuinely platform-specific — permissions, notifications, publishing — is treated as such instead of hidden under a layer that pretends it is not there.
- A single Flutter codebase, with the native layer isolated and declared.
- Business logic lives on the server, not split across two apps.
- Offline state with a defined conflict resolution, not "it syncs by itself".
- Store accounts in the client name, with access handed over and documented.
- Versioning and release channels: internal, testing, production.
- Crash reporting in production, so you hear about it before a user reports it.
- Flutter
- Dart
- Android
- iOS
How it is delivered
From idea to both stores.
Discovery
What people do today, at what moment, and with what in their hands.
Prototype
A navigable flow on the phone, open to criticism before it is built.
Build
Reviewable releases through an internal channel, not one version at the end.
Publishing
Store listings, review cycles, permissions and privacy policy.
Operation
Updates, crash tracking, and compatibility with new OS versions.
Flutter is part of our declared stack and mobile development is part of the team’s work, but there is no published app we can show by name in /case-studies yet. We would rather say it on this page than in the second meeting.
Does an app actually make sense for you?
Tell us where and how the work happens today. Sometimes the answer is that it does not.