Who this is for
This service is for organisations that need an app on people’s phones, whether for customers, field staff, partners or members. Typical reasons are that users need the app to work offline, use the camera, location or other device features, receive notifications, or open it many times a day where a website would feel slow to reach.
It also suits teams that already have an app which has become hard to change, or which is falling behind store requirements, and want to decide whether to update or rebuild it.
How we approach a project
- Discovery. We agree the users, the core tasks and the measure of success. We list what the first release must include and what can follow later. A smaller first release reaches real users sooner, and their feedback is more useful than assumptions.
- Design. User flows, then wireframes, then visual design. We prototype tricky interactions so you can try them on a phone before they are built.
- Build. App and back end are developed in short cycles. You get test builds on your own device throughout, not only at the end.
- Test. We test on a range of devices and OS versions, with slow and dropped connections, and with permissions denied as well as granted, because that is how apps fail in real use.
- Release. We prepare store listings and privacy disclosures with you, submit, and respond to review feedback. Where a store offers staged rollouts, we can release a new version to a portion of users first.
- Handover and after launch. Code, documentation, keys and a release runbook. Crash reporting and analytics are set up so you can see how the app behaves in use.
Decisions we help you make
Native or cross-platform
- Native development uses each platform’s own languages and tools. It gives the most direct access to new OS features and is usually the safer choice for apps that are heavy on graphics, hardware or background processing. It means two codebases.
- Cross-platform frameworks let one codebase target both Android and iOS. Teams commonly choose between a few established options. They suit most business apps such as forms, lists, accounts, payments and content, and they reduce duplicated effort. Some features still need platform-specific code.
- Progressive web apps run in the browser and can be added to the home screen. They avoid store review but their access to device features is more limited than a native app’s, so check your feature list against what browsers support.
We recommend based on your feature list, who will maintain the app and how important it is to adopt new OS features quickly.
Offline behaviour
If users will be in basements, warehouses, rural areas or on the move, decide early what the app should do without a connection. Read-only offline access is fairly simple. Editing data offline and syncing later needs careful design for conflicts, and it affects the back end as much as the app.
Accounts, sign-in and data
We help you decide whether users need accounts at all, which sign-in methods to offer and what data the app really needs to collect. Collecting less makes privacy disclosures simpler and reduces risk.
App store requirements
Both stores review apps against published rules, and these rules shape design:
- Apple states that every app on its App Store is reviewed, and guideline 5.1.1(v) requires apps that support account creation to offer account deletion within the app.
- Google Play’s account deletion requirement asks for both an in-app path and a web page where users can request deletion of their account and associated data.
- Apple requires App Privacy Details for new apps and updates, covering data collected by third-party code in your app as well. Google Play requires developers to complete the Data safety form, even for apps that collect no user data.
- Google Play requires new apps and updates to target a recent Android API level, so even a finished app needs periodic updates to stay available to new users.
We build these requirements into the design from the start rather than discovering them at submission.
Security and quality built in
- Security. We use the OWASP Mobile Application Security Verification Standard (MASVS) as a reference. It groups mobile security requirements into areas such as storage, cryptography, authentication, network communication, platform interaction, code quality, resilience and privacy. In practice that means no secrets stored in the app, sensitive data kept in the platform’s secure storage, encrypted connections, and server-side checks that do not trust the app.
- Personal data. For apps used by people in India, the Digital Personal Data Protection Act, 2023 gives individuals a right to correction and erasure of personal data they consented to share. That right is among the provisions being brought into force in phases under a 13 November 2025 notification. Store policies already push apps towards clear consent and deletion flows, and we build these in a way your legal advisers can review.
- Permissions. We ask for device permissions only when a feature needs them, with an explanation, and we make sure the app still works sensibly if the user says no.
- Quality. Automated tests for core logic, crash reporting, and a release process that produces repeatable, signed builds.
What we need from you to start
- A description of the users, the problem and the core tasks the app must support.
- A decision-maker who can review test builds and give timely feedback.
- Your own Google Play Console and Apple Developer accounts, or a plan to create them in your organisation’s name. We can explain what each needs.
- Access to the systems the app must connect to, with test accounts and API documentation if available.
- Brand assets and any existing design guidelines.
- Your privacy policy, or a lawyer or owner who will produce one. Both stores require a privacy policy link (Apple guideline 5.1.1(i), Google Play User Data policy).
If some of this is not in place yet, we can work through it with you during discovery. Contact us to talk about your app.