Who a mobile app is for
Mobile app development for small business is worth the investment when people need your service in their pocket: on site, on the road, or without reliable internet. A website cannot send a push notification, scan a barcode with the camera or keep working in a basement car park.
Common cases:
- Apps for customers: booking and rebooking for a clinic or salon, ordering ahead and loyalty for a cafe group, delivery tracking for a transport business.
- Apps for staff: job sheets, photos and sign-off for trades on site; stocktake by barcode for a wholesaler; checklists and incident forms for hospitality or logistics crews.
- Apps that extend a system you already have: a mobile front end to your booking, job or stock system.
Not every idea needs an app. If your customers would use it only now and then, a well-built website usually serves them better, and we will say so. Our work page lists projects of this kind, including a taxi booking and delivery platform.
Problems a mobile app solves
An app earns its place when it removes problems like these:
- Paper job sheets and checklists that reach the office late, incomplete or not at all
- Site photos sent by text message and never attached to the job
- Staff who cannot look up or record anything where there is no signal
- Customers phoning to ask where a delivery or booking is up to
- Appointment reminders and offers that sit unread in email
- Stocktakes written on paper and typed in afterwards
What is included
App design
Screen flows and clickable prototypes that follow the conventions iPhone and Android users expect, checked for one-handed and outdoor use.
iOS and Android build
One Flutter codebase producing both apps, so features arrive on both platforms together.
Back end and admin panel
The server, database and web dashboard behind the app, where your staff manage users, content and orders. Prices, rosters and messages are changed there once and reach every phone.
Device features
Push notifications, camera and barcode scanning, location, biometric sign-in, and offline storage that syncs when the connection returns.
Store publishing
Store listings, screenshots, privacy details and review submissions, lodged under your own developer accounts. If you do not have the accounts yet, we set them up with you.
Testing on real devices
Automated tests, plus test releases to your own phones before anything reaches the public.
What you hold at the end
- The iOS and Android apps, published under your own Apple and Google developer accounts
- Full source code for the apps and back end, in a repository you control
- Signing keys and store credentials, held by you
- Administrator access to the back end, database and admin panel
- Firebase and cloud projects owned by your business account
- Store listing text and screenshots
- Technical documentation and an admin guide for your staff
- A written release procedure for publishing later updates
- Test results from the final release, and a training session
Technologies we use and why
Flutter
A toolkit for building iOS and Android apps from a single codebase. One build effort covers both platforms, which keeps cost and upkeep down.
Firebase
Managed services that run on Google Cloud. We use it for sign-in, the Cloud Firestore database, file storage and push notifications. There are no servers for you to look after, and capacity grows with use.
Crashlytics and App Distribution
Firebase tools that report crashes from real devices and deliver test releases to your testers before launch. You learn about a fault from a report, not from a poor review.
SQLite
A small database stored on the phone itself, used so the app keeps working offline. It carries no licence fee.
Swift and Kotlin
The native languages for iOS and Android. We use them for the occasional feature Flutter cannot reach directly, and keep that code small.
Node.js and TypeScript
For a custom server and API when the app must connect to your existing business systems.
How we deliver a mobile app
| Stage | What happens |
|---|---|
| 1. Discovery call | A free conversation about who will use the app, on which devices, and what it must do on day one. We also check whether an app is the right tool. |
| 2. Plan and quote | You receive screen flows, a feature list split into must-have and later, and a written fixed or staged quote. |
| 3. Build and test | We build in stages and send test releases to your phone at regular demos, so you use the real app as it grows. Automated tests run on every change. |
| 4. Launch and train | We prepare the store listings, submit for review under your accounts, move any existing data and train your staff on the admin panel. |
| 5. Ongoing support | Phones and store rules change, so apps need upkeep. A support plan covers crash monitoring, operating system updates, store resubmissions and new features. |
Engagement options
| Option | Suits | How it works |
|---|---|---|
| Fixed quote | A first release with an agreed feature list | A written price covering design, both apps, the back end, testing and store submission. |
| Staged pricing | Larger apps, or ideas worth proving with a small first version | A first release with the core features, then further stages quoted one at a time as you learn from real use. |
| Monthly plan | Apps that are live and in daily use | Monitoring, operating system and store updates, fixes and an agreed allowance for improvements. |
Developer account fees and any store commissions are set by Apple and Google and paid to them directly.
Security and data handling
A phone can be lost, shared or left unlocked, so the device is treated as the weakest point.
- Collect less. The OAIC's mobile privacy guide for app developers advises: only collect personal information that your app needs to function, and secure what you collect. The app requests a permission, such as location or camera, only when a feature needs it.
- Access control. Every user has their own account. Rules on the server decide what each account may read or change, so access never depends on the app alone. The admin panel uses multi-factor authentication, with roles limited to what each job needs.
- Encryption. Data travels over encrypted connections and is encrypted where it is stored. Only what offline work requires is kept on the phone.
- Where data is stored. Google lists Sydney and Melbourne among its Cloud Firestore locations and notes the location cannot be changed once a database is created, so the region is chosen with you before the build starts.
- Backups and deletion. The database is backed up automatically, and users can ask for their account and data to be deleted.
The Australian Signals Directorate says the Essential Eight was designed to protect internet-connected information technology networks, not enterprise mobility. We therefore apply its relevant strategies (patching, multi-factor authentication, restricted administrative privileges and regular backups) to the back end, the admin panel and the accounts around the app.
Support after launch
On a support plan we read the crash reports, test the app against new iOS and Android releases, keep the back end patched and resubmit to the stores when their rules change. A fix on the back end takes effect straight away. A fix inside the app goes through Apple's and Google's review first, and they control that timing, not us.
Report a fault or ask for a change by email at hello@comingwave.com.au, by phone or through the enquiry form. We reply within one business day.
Industries this suits
Trades and construction
Job sheets, site photos and customer sign-off captured on the phone, including where there is no signal.
Hospitality
Order-ahead and loyalty for customers, and opening or closing checklists for venue crews.
Logistics and transport
Driver apps for run sheets, proof of delivery and live job status that customers can follow.
Retail and e-commerce
Barcode stocktakes for staff, and a loyalty or reorder app for regular customers.
Store accounts and privacy: what Apple, Google and the OAIC say
Your own developer accounts. We publish under accounts your business owns, so the app, its reviews and its users stay with you. Apple's enrolment page says an organisation must be a legal entity, must have a D-U-N-S Number so Apple can verify it, and needs a publicly available website; the organisation's name is then displayed as the seller name on the App Store. Google Play offers two developer account types, Personal and Organization, each with its own verification steps. Google also states that personal accounts created after November 13, 2023 must meet specific testing requirements before an app can be made available. We walk you through enrolment.
Review rules. Apple's App Review Guidelines require every app to link to its privacy policy in the store listing and inside the app, and an app that supports account creation must also offer account deletion within the app. We build these in from the start so review is not held up.
Australian privacy law. Where the Privacy Act applies to your business, the OAIC's Australian Privacy Principles include taking reasonable steps to protect the personal information you hold from misuse, interference and loss. We design an app's sign-in, storage and permissions with that in mind. This is general information, not legal advice.
Mobile app questions
Do we need separate apps for iPhone and Android?
No. We build both from one Flutter codebase, so you get an iOS app and an Android app from the same work. Each is still published separately in its own store.
Why should the app be published under our own Apple and Google accounts?
Because the account holder controls the app. Under your accounts, the listing, reviews, users and any revenue are yours from the first day, and you can change developers without transferring anything.
Can the app work without an internet connection?
Yes, where the design calls for it. Data is stored on the phone and synced when a connection returns, which suits site work, deliveries and stocktakes. We agree which features must work offline during planning, because it affects the build.
Is a mobile app better than a mobile-friendly website?
It depends on use. An app suits frequent use, offline work, push notifications and device features such as the camera. For occasional visits, a website costs less to build and needs no install. Tell us the use case and we will give a straight answer.
Can the app connect to our existing booking, stock or accounting system?
Usually, provided that system offers an API, which is a documented way for software to exchange data. We check this during planning. See business systems and integrations.
What upkeep does an app need after launch?
Apple and Google release new operating system versions and update their store rules, and an app has to keep pace to stay listed and working. A support plan covers those updates along with crash monitoring and fixes.
Can a staff app be kept out of the public app stores?
Yes. Apple lets a developer offer a custom app to named organisations for internal use, and Google Play supports private apps available only to chosen organisations. Which route fits depends on how your staff phones are managed, so we settle it in the plan.
How do updates reach people who already have the app?
Each new version is submitted to the stores and, once approved, is delivered through the App Store and Google Play. Phones with automatic updates switched on install it without the user doing anything. Content held on the back end, such as prices or opening hours, changes without a new release.
