Custom mobile applications

Area: Mobile Applications · Usual shape: app + backend + admin panel · Platforms: Android and iOS

An app takes up space on somebody’s phone, and that space is neither easily given nor kept unless the app earns it. We work out first what would make someone open it a second time, then design it, build it, publish it to the stores, and carry on through the versions after that — because release is the first day of an app’s life, not the last.

Talk to us about your project See the whole area

Opens WhatsApp. Nothing is sent until you press send there.

What this solves

Customers keep asking for an app and nobody is sure what would actually go in it.
The service needs a notification, a camera or offline use, and a website is not enough.
You have a design or a prototype and nobody to build it.
The current app is dated and unused, and nobody knows why.

What we build

Product definition: who uses it, why they come back, and what is left to version two.
A screen and flow map before any design work starts.
The full design, in Arabic and English together.
The application itself for phones and tablets, on Android and iOS.
The backend and interfaces the app needs, where they do not already exist.
Accounts and permissions, notifications, and behaviour on a weak connection.
An admin panel for the app’s content and its users.
Release preparation and the versions after launch, including new OS releases.

Where it is used

A service a customer deals with repeatedly — ordering, booking, tracking.
A product that needs to reach the user rather than wait to be visited.
A business that depends on location, a camera or scanning.
An existing web product that needs a real phone version rather than a shrunken one.

What this does not include

We do not guarantee store approval; we prepare for it and handle the feedback, but the decision is not ours.
We do not name a framework or platform before scope — the choice follows the requirements.
We do not build games.
We do not supply devices or accessories, or deal with manufacturing them.
Apps for field teams have different requirements and their own page.

How the work goes

A definition session: what the app does in one sentence, who uses it, and what is deferred.
Screen design and a clickable prototype before building, because changing a screen is cheaper than changing code.
Building in visible stages, with a test build reaching your own phone early.
Release to both stores, then a first version based on what actual use revealed.

Business & field-team apps
when the user is your staff, not your customer.
Product & app interface design
when design alone is what is needed at this stage.
API design & development
when you have a system the app needs to reach.
Ongoing maintenance & support
to keep the app current with phone OS updates.

Questions about this service

Do you build for both Android and iOS?

Yes. Whether that is one build serving both or two separate ones is decided on what the app actually needs, and written into the scope with its reason.

Who owns the store account and the code?

You do. The store account is created in your company’s name and the code is handed over to you. We publish on your behalf if you want, without that changing ownership.

Does the app need a server?

Usually yes, even a simple one: accounts, data and notifications all need something behind them. If you do not have one, it is in the scope from the start rather than appearing later.

What happens after launch?

Phone OS updates alone create periodic work, before any new feature. We agree an arrangement for that before launch rather than after.

Can we start with a small release?

Yes, and it is usually what we suggest: the shortest path that delivers something real, then build on it with what use reveals.

Tell us what the app should do.

Talk to us on WhatsApp Or send the details through the form