A mobile app is a larger commitment than it first appears. Behind the screens users see, it needs an admin portal for your staff, a server that holds the data, connections to your existing systems, and a process for publishing updates to Apple's App Store and Google Play. Many app projects stall because the work behind the idea, such as who approves a booking or how a refund is handled, was never written down.
Kemlat starts with the service the app must deliver and the people on both sides of it: users on their phones and staff who run the service. We design the user flows and screens, build the app with its admin portal and integrations, and test on real devices before preparing the store submissions. The aim is an app your team can operate from the first day, not one that only works in a demo.
How we work
- 01
Understand the service
We interview the business owners, the staff who will run the service and a sample of target users. We list what each type of user needs to do and which existing systems hold the data.
- 02
Design flows and screens
We map each user flow, such as sign-up, ordering or booking, then design the screens and a clickable prototype. Users and staff try the prototype before development, while changes are still easy to make.
- 03
Build the app and admin portal
We develop the iPhone and Android app, usually from one shared set of code, together with the server and a web portal for your team. Work is delivered in short cycles so you can review features as they become ready.
- 04
Integrate and automate
We connect the app to payment providers, maps, notifications and your internal systems as agreed. Routine actions, such as confirmation messages and status updates, are sent automatically.
- 05
Test and prepare publishing
We test on a range of devices and operating system versions, then prepare the store listings, screenshots and privacy details. The app is submitted under your own developer accounts, and we answer the reviewers' questions.
- 06
Monitor after release
We follow crash reports, ratings and key actions after release and plan the first round of fixes and improvements with you.
What you receive
User flows and screen designs
Mapped flows for each user type and approved screen designs in Arabic and English.
Clickable prototype
A prototype tested with users that shows how the app will work before development.
iPhone and Android app
The working app built to the agreed features, with secure login and user roles.
Admin portal and server
A web portal where staff manage users, content, orders or bookings, plus the server and database behind it.
Payment and system integrations
Connections to the payment, notification and internal systems listed in the scope.
Store submission package
Tested builds, store listings and privacy information ready for Apple and Google review.
What changes for you
- Users complete the core tasks on their phones without calling your staff.
- Staff run the service from an admin portal instead of spreadsheets and phone calls.
- Crashes are reported automatically, so the team can find and fix them quickly.
Where this service sits in the KEMLAT Method
Scope: Apple and Google developer accounts, and paid services the app relies on such as maps, messaging or payment gateways, are paid by you directly to those providers. Approval in the stores is decided by Apple and Google.
Questions clients ask
Do we need separate apps for iPhone and Android?
Usually not. Most business apps can be built once with a cross-platform tool, which produces the iPhone and Android versions from the same code, and released in both stores. Separate builds make sense only when the app relies heavily on specific device features or speed.
Should we start with a mobile app or a web app?
If users need the camera, background location or dependable notifications, a store app is often the right choice. If they mainly fill in forms and view information, a progressive web app may be enough. We recommend one after the first workshops.
Who owns the code and the store accounts?
The app is published under your organisation's developer accounts, and the source code is handed over as set out in the contract. This lets you continue with us or with another team later.
What happens if Apple or Google rejects the app?
Rejections are common and usually concern privacy details, login rules or gaps in the listing. We fix the points the reviewer raises and resubmit.
How are updates handled after release?
Defects found after release are fixed as agreed in the scope. New features and changes needed for new operating system versions can be planned as further work or covered by a monthly maintenance service.
Related services
All servicesStart with a conversation
Tell us where you are today. We will suggest the right first step, with no obligation.