How to get a business app built in Mauritius

The short answer

Getting an app built well comes down to six decisions, in this order:

1. Write down the one job the first version must do, for whom, and how you will know it works.
2. Choose the format: a web app, a native app, or one cross-platform app for iOS and Android.
3. Plan the hidden half: the backend, the admin portal your team uses, and the integrations.
4. Open the App Store and Google Play accounts in your company’s name, and keep them.
5. Design for the Data Protection Act 2017 from the start, not after launch.
6. Budget for life after launch: OS updates, store policy changes, fixes and new features.

The rest of this guide takes each decision in turn, then shows what drives the cost and how to brief a developer so the quotes you receive can be compared.

1. Decide what the app must do

Most app projects that go wrong started with a feature list instead of a problem. Before talking to developers, answer these in a page or less:

• Who uses it? Customers, your field staff, partners, or several of these with different rights.
• What do they do today without it? WhatsApp messages, paper forms, phone calls, spreadsheets. This is what the app replaces.
• What is the one task the first version must handle end to end? A booking, an order, a daily log, a check-in.
• What must your team see or control? Approvals, stock, payments, reports.
• Which systems must it talk to? Accounting, CRM, POS, a payment gateway, an existing website.
• Does it need to work offline? On a boat, a farm or a building site, often yes.

Keep the first version narrow. An app that does one job well and is used every day is a better base than one that does ten jobs and is opened once. Features that can wait go on a written list for version two.

2. Web app, native or cross-platform?

A useful rule: if people will use it every day or need the camera, push notifications or offline mode, build an installable app; if they will use it occasionally, start with a web app. Many projects combine both. In the boat tour booking app we built, customers book through a web link with nothing to install, while staff use the iOS and Android app to manage trips and check passengers in, even offline at sea.

3. The backend and the admin portal

The app on the phone is often the smaller part of the work. Behind it sit:

• A backend: accounts and login, the database, file storage, notifications and scheduled tasks such as reminders or daily reports.
• An admin portal for your team: managing users, content, orders or bookings, approving payments, seeing reports. It usually runs in the browser.
• Roles and permissions: who sees what. A sales representative may only see their own customers; a manager sees everything.
• Integrations with the systems you already use.

Ask for the admin portal to be scoped in the same quote as the app. It is where your staff will spend their time, and it is often forgotten until late. The poultry farm management app we built shows the pattern: farmers log their flocks in the app, while the company’s technical and sales teams work from a web portal on the same data.

4. Store accounts in your company’s name

To publish on the App Store and Google Play, someone needs a developer account with each. Open both in your company’s name, not the developer’s, and give the developer access as a team member. If the app is published from the developer’s account, moving it later is slow and sometimes means publishing it again as a new app, losing its reviews.

• Apple Developer Program: enrolling as an organisation requires a legal entity and a D-U-N-S number registered to it. Apple checks that the legal name matches the Dun & Bradstreet record, so request the number early. There is an annual membership fee.
• Google Play Console: organisation accounts also need a D-U-N-S number. There is a one-off registration fee. Newly created personal accounts must first run a closed test with at least 12 testers for 14 days before they can publish to production, so an organisation account is usually the better choice for a business.
• Store review: both stores review every release. Apps that let people create an account must also let them delete it from within the app, and apps with user-generated content need ways to report and block users. Both stores ask for a privacy policy and a description of the data the app collects.

The same rule applies to everything else: the domain, the cloud project, the database and the code repository should be in your name or transferable to you, and the contract should say when ownership of the code passes to you.

5. Data protection under the Data Protection Act 2017

Apps collect personal data almost by definition: names, phone numbers, locations, photos, orders. In Mauritius, the Data Protection Act 2017 applies to that data, and your business is responsible for it as the controller, even when a developer builds and hosts the app. Points to settle at the design stage:

• Collect only what the app needs, and say why in a privacy notice inside the app and on the store listing.
• Ask for consent where you rely on it, for example for marketing messages or location tracking, and make it as easy to withdraw.
• Secure the data: encrypted connections, access limited by role, and two-factor login for administrators.
• Choose where the data is stored, and check how transfers outside Mauritius are covered when the cloud region is abroad.
• Plan for people’s rights: access to their data, correction and deletion, including deleting an account from the app.
• Plan for incidents: the Act requires the controller to notify the Data Protection Commissioner of a personal data breach without undue delay and, where feasible, within 72 hours of becoming aware of it.
• Check registration: controllers and processors must register with the Data Protection Office.

If your users are also in the European Union, the GDPR applies to their data as well. Ask your developer how each point is handled, and have your privacy notice reviewed by someone qualified.

6. Maintenance and OS updates

An app is not finished at launch. Apple and Google release new versions of iOS and Android every year, change their store policies and periodically require apps to target newer system versions. An app that nobody updates eventually stops working well, or is removed from sale. Plan for:

• Compatibility updates for new iOS and Android versions.
• Security patches for the libraries the app uses.
• Monitoring of crashes and performance, so problems are found before users report them.
• Store resubmissions when policies change.
• A backlog of improvements from what users actually do.

Ask for maintenance as its own line in the quote, with what it covers and how quickly the developer responds when something breaks.

What drives the cost of an app

We do not publish prices for custom apps, because two apps with the same name can involve very different amounts of work. These are the factors that move a quote:

• The number of distinct screens and user roles, more than the number of features on a list.
• The format: a web app, one cross-platform app, or two native apps.
• The admin portal and how much your team must manage from it.
• Integrations: payment methods such as MCB Juice, card payments or Stripe, accounting, CRM, POS or an existing database.
• Offline mode and sync, which add real complexity.
• Languages: English, French or both, for the app and the store listings.
• Design: adapted components or a fully custom interface.
• Maintenance after launch.

A fixed written quote should list each of these so you can see what you are paying for and compare offers fairly.

How to brief a developer

Send every developer the same brief. It does not need to be technical:

1. Your business in a few lines, and the problem the app solves.
2. The users and what each one must be able to do.
3. The one task the first version must handle end to end.
4. What your team must see and control in the admin.
5. The systems it must connect to, and the payment methods your customers use.
6. iOS, Android, web, or all three, and the languages.
7. Whether it must work offline.
8. Apps you like, and why.
9. Your deadline, and any date that cannot move.
10. Who will look after the app after launch.

Then ask each developer the same questions: which live apps they have shipped (open them on your phone), who will build yours, which technology they recommend and why, whose name the store accounts and code will be in, how they handle personal data, and what maintenance includes.

How Artover builds apps

We build iOS and Android apps in Cybercity Ebene, mostly with React Native and Expo, together with the web portal and the Firebase or Node.js backend behind them, and we handle App Store and Google Play submission. You can open real projects in our portfolio, such as a second-hand marketplace app live on the App Store in Mauritius, with MCB Juice payments checked before an order proceeds.

Every project starts with a free discovery call and ends in a fixed written quote. See mobile app development in Mauritius for how we work, or send your brief through the quote form.