Your business has a web application that works. Your team uses it from their desks. Your clients use it from their laptops. It does what it needs to do.
But now you have field staff who need access from their phones. Or clients who want to check status on the go. Or operations that would be faster with a camera, GPS, or push notifications that only a mobile device can provide.
You do not need to rebuild your entire system. You need a companion mobile app that connects to what you already have.
A Mobile App Is Not a Second System
The most expensive mistake businesses make when thinking about mobile is treating it as a separate project that duplicates the web system. Rebuild the user interface. Rebuild the business logic. Rebuild the data storage. This is how mobile projects get quoted at R500,000+ and take a year.
A companion mobile app is different. It shares the same backend as your web application. The same database. The same business logic. The same API. The mobile app is a new interface to the same system, not a copy of it.
What the mobile app does:
- Presents the data and functionality your mobile users need (which is often a subset of what the full web application does)
- Takes advantage of mobile-specific capabilities (camera, GPS, push notifications, offline access)
- Connects to your existing backend through the same API your web application uses (or through an API you build for this purpose)
What the mobile app does not do:
- Duplicate your backend logic
- Store a separate copy of your data
- Require a separate team to maintain business rules
This approach means changes to business logic, pricing, permissions, or workflows happen once (in the backend) and both the web app and mobile app reflect them.
When a Companion App Makes Sense
Field staff need access. Delivery drivers checking routes and confirming deliveries. Technicians viewing work orders and uploading photos. Inspectors completing checklists on-site. Sales teams checking inventory and placing orders from a client's office.
Clients want self-service on mobile. Checking order status. Viewing reports. Approving requests. Accessing documents. These are read-heavy, simple interactions that work well on mobile.
Mobile device features add value. Scanning barcodes or QR codes. Capturing photos and attaching them to records. Using GPS for location tracking or geofencing. Push notifications for time-sensitive alerts.
Offline access is needed. Field workers in areas with poor connectivity need to complete tasks offline and sync when they are back online. This is a specific mobile capability that web applications handle poorly.
Technology Choices
React Native (Cross-Platform)
One codebase produces both an iOS and Android app. This is the most cost-effective approach for most business companion apps.
Advantages: One development effort for both platforms. Faster development. Easier maintenance. Shared logic with web applications built in React.
Tradeoffs: Performance is slightly below native for graphics-intensive applications. Some device-specific features may require native modules.
Best for: Business applications, data entry forms, dashboards, simple workflows, reporting.
Native (Swift for iOS, Kotlin for Android)
Separate codebases for each platform. Each app is built specifically for its operating system.
Advantages: Best possible performance. Full access to every device feature. Best user experience for complex, interaction-heavy applications.
Tradeoffs: Two codebases to maintain. Two development efforts. Roughly double the cost and maintenance burden.
Best for: Applications where performance is critical, heavy animation or graphics, or applications that need deep OS integration.
Progressive Web App (PWA)
A web application that is enhanced for mobile use. Not a native app from the app store, but a web app that can be "installed" on the home screen and work offline.
Advantages: No app store submission. No separate codebase. Works on any device with a browser. Easy to update.
Tradeoffs: Cannot access all device features (limited push notification support on iOS, no access to some hardware APIs). Offline support is more limited than native. No app store presence.
Best for: Simple mobile access to existing web applications where native device features are not critical.
For most business companion apps, React Native is the right choice. It balances cost, performance, and cross-platform reach.
What It Costs
A focused companion app (3-5 screens, read-heavy, connects to existing API): R60,000 to R120,000. Timeline: 4 to 8 weeks.
A full-featured companion app (10+ screens, data entry, camera/GPS integration, push notifications, offline support): R120,000 to R300,000. Timeline: 8 to 16 weeks.
A complex companion app (multi-role app with different views per user type, complex offline sync, real-time data, custom device integrations): R300,000 to R500,000+. Timeline: 3 to 6 months.
These ranges assume your web application already has an API (or one can be added). If your web application has no API and one needs to be built first, add R30,000 to R100,000 for API development.
The Backend Question
If your existing web application has a well-structured API, building a companion mobile app is straightforward. The mobile app calls the same endpoints your web app uses.
If your web application does not have an API (common with older WordPress, PHP, or monolithic applications), you need to build one. This is often the most valuable part of the entire project, because the API serves not just the mobile app but also opens the door to future integrations, third-party access, and other applications.
The API development is a separate piece of work, but it is not wasted effort. It makes your system more capable overall.
A Real Example
I built a web and Android application for a water quality reporting project. The system needed to work both as a web application (for office-based data analysis and reporting) and as a mobile application (for field workers collecting water quality samples and entering data on-site).
The mobile app shares the backend with the web application. Field workers use the mobile app to capture sample data, including location and photos. Office staff use the web application for analysis and report generation. Both interfaces work against the same data.
You can see the project at /projects/react-based-project-on-water-quality-report-tootle-that-needs-to-run-on-with-an-web-and-android-app.
Before You Build
Define what mobile users need (not everything). Your web application has 50 features. Your mobile users probably need 10. Define the mobile use cases specifically. Field workers need X, Y, Z. Clients need A, B, C. Keep the mobile scope focused.
Check if your web app has an API. If yes, the mobile project is simpler. If no, plan for API development as phase one.
Decide on platforms. Do your users use iOS, Android, or both? If both, React Native is almost always the right choice for cost and maintenance reasons.
Plan for maintenance. Mobile apps need updates when operating systems release new versions. App stores have review processes. Push notification certificates expire. Budget for ongoing maintenance, not just the initial build.
The Short Version
Adding a mobile app to your existing web system does not mean rebuilding everything. A companion app shares your existing backend, serves mobile-specific needs, and takes advantage of device capabilities. React Native makes cross-platform development cost-effective. Start with a focused scope, connect to your existing API, and expand based on how your team actually uses it.
If your web application needs a mobile companion, let us talk about what that looks like.