//mobile-engineering
Native & cross-platform mobile engineering
iOS and Android applications built for your organisation, published under your own developer accounts, with the source code in your repository from the first commit.
We build business mobile applications: field-service tools, warehouse and logistics clients, B2B ordering apps, inspection and compliance apps, and customer-facing products for companies that sell to their own customers. The work is contracted, scoped and delivered as software you own.
Which technology fits is a decision we make with you, not a preference we impose. A single-platform pilot with heavy device integration is usually native. A product that must reach both platforms on one budget is usually React Native or Flutter. We will tell you which we think is right for your case and why, including the cases where the answer is that you do not need a mobile app at all.
Capabilities
What we build and review
Native engineering
Where platform capability, performance or hardware access decides the outcome.
- Swift and SwiftUI for iOS and iPadOS
- Kotlin and Jetpack Compose for Android
- Bluetooth, NFC, camera, location and background processing
- Widgets, share extensions and platform integrations
Cross-platform engineering
One codebase across both platforms, with native modules where they are genuinely needed.
- React Native with TypeScript
- Flutter and Dart
- Shared design system across both platforms
- Native bridges for device features the framework does not cover
Data, sync and offline
Most business applications are used where the network is not.
- Offline-first local stores and conflict resolution
- Background synchronisation and retry strategies
- Push notification architecture
- Efficient payload design for poor connectivity
Release engineering
Getting a build out repeatedly and safely is engineering work in its own right.
- CI/CD pipelines with signed, reproducible builds
- Automated UI and integration test suites
- Staged rollouts, feature flags and crash monitoring
- App Store and Google Play submission support for your accounts
How an engagement runs
From brief to a maintained application
The same four stages run whether the engagement is a six-week pilot or a two-year product.
- 01
Scoping
A working session with your team. We leave with a written scope, an effort estimate per discipline and the open questions that still carry risk.
- 02
Architecture
Data model, offline strategy, API contract and platform decisions, documented before implementation starts so the choices are reviewable.
- 03
Build
Two-week increments against your repository, each ending in an installable build your team can use, not a status report.
- 04
Release & maintain
Store submission support, monitoring, and an agreed maintenance arrangement for OS updates and defect fixes.
Engagement models
Three ways to work with us
- Fixed-scope project
- A defined deliverable with acceptance criteria and a fixed price. Best when the requirements are stable and the outcome is easy to describe.
- Dedicated team
- A named engineering team working to your backlog for an agreed period, billed monthly. Best for evolving products where scope is discovered as you go.
- Embedded specialists
- One or two of our engineers working inside your existing team, under your technical lead. Best when you need specific platform depth rather than a whole team.
We do not publish a rate card, because the honest answer depends on scope, duration and the team shape a project needs. Every engagement is priced in a written proposal after a scoping session.
Common questions
- Who owns the code?
- You do. Work is committed to your repository from the start, and the contract assigns all intellectual property in the deliverables to your company on payment.
- Whose developer accounts are used?
- Yours. The application is published under your own Apple and Google developer accounts so the listing, the reviews and the relationship with the platform belong to you.
- Can you take over an existing app?
- Often, yes. We start with a paid technical assessment of the existing codebase and give you a written opinion on whether to continue it, refactor it or replace it, including the case for doing nothing.
- Do you work with our in-house developers?
- Frequently. Mixed teams work well when responsibilities and code review boundaries are written down at the start, which is part of the scoping deliverable.
Scope of our services
We are a business-to-business engineering company. Here is what we do not do.
We work only with companies and public-sector organisations, under a written contract signed before any work begins. We do not advertise or provide services to private individuals, and we are not affiliated with, and do not act on behalf of, Apple, Google, Microsoft or any other platform vendor.
- Consumer remote technical support, helpdesk or PC / phone "tune-up" services
- Device repair, unlocking, data recovery or password / account recovery
- Resale of third-party software licences, subscriptions or mobile applications
- Any unsolicited contact about a problem detected on your device — we never do this
- Services to private individuals; every engagement is a business-to-business contract
Tell us what you need built.
Send a project brief and a member of the engineering team will reply with questions, an approach and a written proposal.