Skip to content
Ayoub
Back to services

Mobile Apps

An app on the phone, for the work that does not belong in a browser.

An app people install and open every day. I build the screens, the account system and the server behind them, then take it through the store review.

What this actually is

A mobile app makes sense when people use it often, or when it needs the phone itself: the camera, the location, notifications, or working with no signal.

The build is only half of it. An app has to keep working when the connection drops, and sync again when it returns. Notifications need permission, and a reason. Old versions stay on people's phones for months, so the server has to speak to more than one version at a time. Apple and Google both review what you publish, and each has rules about accounts, deletion and payment.

I build the app and the server it talks to, so one person answers for both. Data, accounts and background work sit on the same stack I use for web products. You get the store listing prepared and the release published, not just a file handed over.

What you get

  • A screen-by-screen plan, agreed before any code is written
  • The app for iOS and Android, from one codebase
  • The server, database and API the app depends on
  • Accounts, sign-in and account deletion that meet store rules
  • Store listing text, screenshots and the submitted release
  • The source code in your repository and a build you can reinstall

Things in this category

  • A booking app for a service, with reminders
  • A delivery or field app for staff on the move
  • A loyalty app for a shop or a chain of shops
  • A learning app with lessons and progress
  • A companion app for an existing web platform
How this one gets built

The same six stages, said in the language of this kind of product.

You tell me the idea

A single conversation, usually about thirty minutes.

We talk until I can describe your idea back to you correctly.

We start with a conversation, in English, French or Arabic. You describe the idea in your own words. I ask questions about who it is for, what they do today, and what you want to happen. I write down what I heard and send it back for you to correct.

What you have at the endA written idea brief: the goal, the user, the assumptions, and what success means.

You see the market gaps

Usually a few days to a week.

I find out what already exists and where it leaves people stuck.

I go through the products your users already use, free and paid. I read what people complain about in reviews, forums and support threads. I look at how competitors charge. Then I write down the gaps that are real, and the ones that are not worth chasing.

What you have at the endA market and competitor report, with the gaps ranked and the evidence linked.

You see the real screens

Usually a week or two.

We decide what the product is, and you see it before it is built.

I turn the gaps into a product you can actually see. First the shape: what it does, who logs in, what each screen is for. Then clickable screens you can open on your phone. You use them, tell me what feels wrong, and I change it before any code exists.

What you have at the endA clickable prototype of the main screens, plus the agreed feature list.

You approve the plan

Usually a few days.

The build gets broken into phases, each with its own scope and price.

A big build in one piece is where projects go wrong. So I split it into phases. Each phase has its own scope, its own price and its own working result. You approve one phase before it starts. You are never asked to commit to the whole thing at once.

What you have at the endA phase plan: scope, price and result for each phase, in writing.

You watch it being built

The longest stage. Weeks to months, depending on scope.

The product gets built in order, and you see it working every week.

I build phase by phase, starting with the part that carries the most risk. Every week there is a real link you can open and use. Nothing is hidden until the end. When something takes longer than I said, you hear it from me first.

What you have at the endA working product on a live link, updated every week, with the code in a repository you own.

You launch, and I stay

Launch takes days. Staying afterwards is ongoing.

The product goes live, and I stay until it is genuinely right.

Going live is a stage, not a finish line. I move it to your domain and accounts, watch the first real users, and fix what they hit. Then I hand over what you need to run it. If you want me to keep going, I stay.

What you have at the endThe live product on your domain, with accounts, code and a short handover guide.

See all six stages in full
What I build

Is this what you need?

If you are not sure which of these your idea is, that is a normal question and a good reason to talk.

Tell me about your ideaOr send a full brief instead
The rest of what I build