Algeria AgencyDevelopment
Mobile app development
An app when it is justified: repeated use, phone hardware, or work without a connection. Otherwise, we will tell you so.
The first question we ask is whether you need an app at all. Many projects that arrive in this shape are better served by a well-built website: cheaper, findable through search, with no installation to persuade anyone into, and no dependence on two app stores.
An app is justified in three cases. Repeated use, where an icon on the home screen genuinely changes how often people come back. A need for phone hardware — continuous camera, notifications, background location. Or work that has to continue without a network, which is a real argument in Algeria rather than a detail.
When an app is justified, we build the smallest version that is useful first. A narrow initial scope, published and used, teaches more in a month than six months of specification, and costs far less to correct.
Weight matters as much as features. An app of several hundred megabytes does not install on a phone whose storage is full, and does not download on a limited data plan. That is a design constraint, not an end-of-project optimisation.
What we usually find
- You were offered an app, without ever being asked what it would be for.
- Your field team writes information on paper and copies it out at the office.
- Your customers have to reinstall or sign in again with every update.
- Your existing app has not been updated in two years and will soon be rejected by the stores.
What changes
Real use, not an icon
A narrow scope people actually use beats a complete app that gets installed and then forgotten.
Usable without a network
The essential functions continue offline and sync on return, which changes everything for a team out in the field.
Published and maintainable
Developer accounts in your name, sources delivered, and a release procedure somebody else can follow.
What you get
Android and iOS
A shared codebase where that fits, two where the difference justifies it. We explain the choice.
Offline mode
Entry and viewing without a network, sync on return, and conflict handling defined in advance.
Notifications
Targeted sending, with a console so you can send them yourself without us.
Controlled size
Install size watched as a design criterion, tested on an entry-level phone.
Store publication
Developer accounts created in your name, listings, screenshots and a documented update procedure.
Usage measurement
Measuring what is actually used, so that what is not can be removed rather than added to indefinitely.
How we work
Check the need
We look first at whether a website would do. If it would, we say so, even when that is a smaller project for us.
Define the smallest useful version
The minimum scope that already helps, with an explicit list of what waits for the next release.
Designs and flows
Screens approved before development, taking account of the screen sizes actually in circulation.
Development and device testing
Built in slices and tested on real phones, including older ones with limited memory.
Publication and handover
Submitted to the stores from your accounts, with sources and the release procedure handed over.
Is this the right fit for you?
This is for you if
- Your users come back often: several times a week, not twice a year.
- You need the camera, notifications, or operation without a network.
- A field team has to record data where there is no connection.
- You accept starting small and adding according to observed use.
This is not for you if
- What you need is to be found by new customers. Apps are not found; websites are.
- Your users would come once or twice. Nobody installs an app for that.
- You want an app "like a website, but as an app". That is a website, and it will cost less.
- You have no budget to maintain it. An unmaintained app gets removed from the stores.
What we commit to
The store accounts are yours
Created in your name, with your access. An app published under the agency’s account is an app you do not control.
We will tell you not to build it
When a website answers the need better, we say so before the quote, including when it costs us the project.
Tested on real phones
Including older models with limited memory, because that is what many of your users are holding.
What matters for an app in Algeria
The device population is very spread out. A significant share of users has an older phone, with little free storage and an Android version that is no longer recent. A heavy or demanding app installs badly, gets deleted quickly, and never shows up in your statistics as a technical problem — it only shows up as disinterest.
Mobile data is counted. An app that downloads unoptimised images every time it opens costs its user money, and that alone is enough to have it deleted. We watch consumption as closely as speed.
Finally, the connection is intermittent rather than absent. The right design is not "offline or online" but "keeps working when it drops": a local queue, sync on return, and a visible state so the user knows where their data stands.
Frequently asked questions
Do I really need an app?
Often no. A fast website covers most needs, is found through search, and has no installation to persuade anyone into. We check that seriously first, and we say so plainly.
Do Android and iOS cost double?
No, in most cases: a shared codebase covers both. The cost doubles mainly when the app needs functions very close to the hardware, and we warn you if your project is one of those.
Who publishes to the stores?
You do, with your developer accounts. We do the submission for you, but the app has to be published under your identity — otherwise you do not control it.
What does maintenance cost?
You should budget for it recurrently, if only to keep up with operating system and store changes. An app without maintenance eventually gets removed, and we would rather tell you before starting.
Can we start from an existing app?
Yes, after a code audit. We will tell you whether taking it over is cheaper than rebuilding, and the answer is not always the one that suits us.
How long until the first version?
It depends on the scope, which is exactly why we push to narrow it. A restricted first version ships considerably sooner and teaches you what the rest should contain.
How to start
Describe what the app has to make possible, for whom, and how often that person would open it.
We come back with an honest answer to the "website or app" question, and if it genuinely is an app, the scope of the first version and its estimate.
What we have written on this subject
Mobile apps: the weight and the asks decide more than the features
What makes people abandon an app is settled before the first feature: the download, the sign-up, the permissions.A published application: what it costs to keep alive
Development ends. The application does not: it ages on its own, on handsets you can no longer reach.Custom software: the specification you write is not the one you need
Nobody knows what they want before using it. A complete specification written beforehand is a guess set down in the present tense.
Let us talk about your project
A free audit, no commitment: we look at your online presence and tell you what is holding it back.
- The store accounts are yours
- We will tell you not to build it
- Tested on real phones