Technology · Mobile
Mobile app development for iOS and Android.
When the solution has to live in the user's pocket - notifications, codes, payments and activity history.
When clients usually bring us in
- the existing system no longer keeps up
- the work happens in spreadsheets
- data is duplicated across systems
- you need a new application
- you want to modernise an old system
- you're building a new digital product
You don't always have to build from scratch
If the existing system can be properly modernised or connected to others, that's usually faster and cheaper than a new application. We start by looking at what's worth keeping.
What this means for you
- Fewer spreadsheets and manual status updates.
- Less duplicated data across systems.
- One view of the process for management and the team.
- A system that grows with the company.
- Less dependence on the one person who knows how it works.
Problem → solution
Capabilities
- user profiles
- QR codes and digital cards
- bookings
- payments
- loyalty and credit
- push notifications
- locations
- activity history
- admin and analytics
- offline mode
How we build
One codebase, both platforms
Unless the project demands native, we build for iOS and Android from one codebase.
Store publishing
Submission, review and updates on your developer accounts, so the app stays yours.
Admin without a developer
An admin area where your team manages content, notifications and users.
Use cases
Loyalty app
A digital card, visits and rewards instead of plastic cards.
Field app
Tasks, photos and reports from site, offline included.
Event app
Programme, tickets, notifications and venue navigation.
When an app is needed and when a website is enough
A mobile app means store submissions, separate maintenance for two platforms and updates the user has to install. That pays off when the solution needs something a browser cannot do, or cannot do well enough.
App
Offline work, push notifications, camera and codes, background location, field work, daily use.
Web
Occasional use, quick changes without waiting on a store, users who will not install anything.
Where the answer sits in between, it often starts as a web solution and the app follows once it is clear what it must do.
Store submission is part of the project
Submission is not a final step but a requirement that shapes development: developer accounts, both stores' rules, a privacy policy, permission descriptions and a review that can take longer than expected. We plan for it in advance, not a week before the deadline.
- developer accounts in both stores, in your company's name
- a privacy policy and a description of the data collected
- an explanation of every permission the app requests
- a test build for your team before release
- a process for updates after release
Working offline
A field app that stops without signal is not useful. But offline is not a switch, it is a decision: what may be entered offline, what happens if two people change the same record, and when data is reconciled.
How we build the system
Architecture
We define the data model, modules and system boundaries before development, so later growth doesn't require a rewrite.
UX/UI
You approve the user journeys and a prototype of the key screens before any feature is written.
Frontend and backend
The interface and the server side are built to one standard: readable code covered by automated tests.
Integrations
Connections to ERP, CRM, document systems and registries, with logging and retries.
Data
Migration, cleanup and data quality rules, so the new system doesn't inherit the old errors.
Security, quality, rollout
Security
Authentication and permissions, encryption in transit and at rest, an audit trail and a review before go-live.
Testing
Automated tests, regression and acceptance testing against your criteria, not ours.
Deployment
Separate environments, phased release and the ability to roll back within minutes.
Handover
Code, access, documentation and team training. The system stays yours.
Maintenance
An agreed response time, monitoring and a monthly allocation for enhancements.
Related work
Technologies
FAQ
Do the two platforms need separate apps?
Not necessarily. One codebase can often serve both; where the solution needs deeper device access, it is judged case by case.
Whose account will the app be published under?
Yours. The store account must be in your company's name, otherwise the app is not yours.
Related solutions
Sounds like your project?
Send us the project description, your existing system, the tender documents or the event date.