Algeria AgencyWeb & software
Website, app or custom software: which one, and in what order
Three very different things share the name "IT project". Choosing the wrong one costs more than building the right one badly.
A director deciding to invest in software is presented with three proposals that look alike on a quotation and have almost nothing in common: a website, a mobile app, a line-of-business system.
They do not solve the same problem, they do not address the same people, and they are not paid for in the same way. Yet they often arrive in the same conversation, presented as levels of ambition for one thing.
That is the commonest cause of failure we meet, and it is not technical. A failed project is nearly always a good project carried out in the wrong category: an app developed where a page would have done, a system written where a spreadsheet was still holding.
This article will not tell you which to choose — that depends on you — but it will give you the question that settles it, the order that works, and the things we refuse to build even when asked.
The three things called "an IT project"
A website answers a question asked by somebody who does not know you yet. It is public, it is read once or twice per visitor, and its quality is measured by what it prevents: a needless call, a wasted journey, a refused order. It is a filtering device as much as a presentation, and that is the part almost nobody designs deliberately.
A mobile app addresses somebody who already knows you and agrees to install you. That is a commitment very few businesses deserve, and its price is a place on a home screen your customers grant to about ten brands in total.
A line-of-business system does not address your customers at all. It addresses your teams, it is used for hours a day, and its quality is measured in data entry time saved rather than in impression produced.
The three have different lifespans. A website is redone every three to five years, an app has to be maintained continuously or it stops working, and a well-built system serves ten years while evolving.
Above all they have different economics. The first is judged on what it brings in, the third on what it saves, and the second on a frequency of use most businesses never reach. Comparing their quotations therefore means comparing three different currencies printed with the same symbol.
The question that settles it: who uses it, and how often
One question separates these three categories properly, and it is about neither budget nor technology: who is going to use this tool, and how many times a day.
If the answer is "people who do not know me, once or twice", it is a website. Nobody installs an app before buying, and no line-of-business system addresses a stranger.
If the answer is "my own teams, all day", it is a line-of-business system, and the website question does not even belong in the same conversation.
If the answer is "my customers, several times a week, over a long period", then and only then is an app worth discussing. That is the case for services consulted out of habit: an account, a tracker, a repeat order.
The trap is the answer "both". It is nearly always true and nearly always premature: it describes the business in three years rather than this quarter’s decision, and trying to serve both at once produces something that serves both badly.
Why a mobile app is rarely the right first answer
It is the most frequent request and the most often unsuitable, and it deserves an explanation rather than a flat refusal.
First because it assumes an installation. Between your advertising and your first use you add an app store, a download, some storage and a decision — four steps a web page does not have.
Then because it is not maintained but tended. Operating systems change twice a year, and an app that stops being updated does not degrade gently: it stops being installable and then disappears.
Finally because it cannot be found. A website answers a search; an app exists only for people who already know it exists, which inverts the acquisition question entirely. Put another way, it assumes solved the problem most of the businesses asking for one are trying to solve.
There are cases where it is the right choice, and they share a property: repeated use by people already acquired, or a need the web does not cover — a camera used continuously, offline use, a notification that has to arrive. If your need is not on that list, start elsewhere.
A spreadsheet is a real system, until a specific moment
Many businesses run on a spreadsheet, and the software industry presents that as backwardness. It is not: a spreadsheet is flexible, free, understood by everybody and editable live by the person who knows the work.
It stops working at an identifiable moment, and it is better to wait for that moment than to anticipate it. The most reliable sign is coexistence: two versions of the same file are in circulation and nobody knows which one governs.
The second sign is re-entry. The same information is typed twice in two different places, producing discrepancies somebody spends time reconciling every week.
The third is simultaneous access: two people need to write at the same time and one waits for the other. The fourth is history: you cannot tell who changed what, and it has started to matter — usually on the day a stock or invoicing discrepancy has to be explained to somebody.
While none of those four signs is present, custom software will cost you money and flexibility for a gain you will not measure. When two are present it becomes cheaper than the spreadsheet — and that is when to call us, not before.
Where you are read, and on which screen
The choice between these three has a material constraint no quotation mentions, and it is measurable.
The internet market observatory published by ARPCE counts, for the second quarter of 2025, some 59.10 million internet subscriptions in Algeria, of which 88.71% are mobile and 11.29% fixed.
The usual reading of that figure is "so we need an app". It is the opposite: it says your audience is on a phone, not that it is willing to install something. A website built for a phone serves exactly the same population without asking them to decide anything.
The figure does have a real consequence for line-of-business software, and it is nearly always forgotten: some of your teams work standing up, in a workshop, on a round or on a shop floor. Software designed for a desk screen becomes unusable there.
The rule that comes out of it is dull and sound: design first for the most constrained screen the tool will actually be used on, and check it with the person who will use it, standing up, in their own environment.
- Mobile subscriptions88.71%
- Fixed subscriptions11.29%
ARPCE, internet market observatory, second quarter of 2025
The order that works
When more than one of the three is justified — which happens — the order matters, and it is nearly always the same.
First, whatever answers the questions you already receive: a page saying what you do, what you do not do, what it costs and how to reach you. It is the cheapest of the three and its effect shows in weeks.
Then whatever saves you time internally, if one of the four spreadsheet signs is present. A line-of-business system has a measurable effect on your margin, which finances what comes next.
Only then, and only if repeated use exists, the app. By that stage you know who would use it, how often and for what — three things you could only guess at the start.
The mirror mistake exists too and is rarer: building a perfect internal tool before having a page that explains what you sell. It happens in businesses run by technical people, and it costs as much as the reverse: an excellent internal tool never makes up for having no customers to feed it.
The shape of the cost: the second year
The cost of a software project is not its development. It is its development plus everything that follows, and the ratio between the two surprises people every time.
A website runs untouched for months, then needs a content update, a correction, an evolution. An app needs work at every operating system change, whether or not there is anything new to ship.
A line-of-business system costs most at the moment it succeeds: as soon as your teams genuinely use it they ask for changes, and those requests are the sign it works rather than a design fault.
The practical consequence is that maintenance has to be budgeted from the first quotation, as an annual percentage rather than a promise. A supplier who does not raise it is selling you something they know they will call you back to invoice for.
We will give you no project cost figures for Algeria: we know of none that is dated and checkable, and the ranges in circulation exist to anchor a negotiation rather than to inform. Ask for three quotations and compare what each one excludes.
Online payment changes the nature of the decision
One question moves the boundary between these three, and it is taking money. A website that collects payment is no longer a brochure: it is a system, with states, failures and edge cases.
The direction of the market is dated: over one year the number of online merchants grew 26%, card transactions on the internet 38%, and the amount paid online 179%, while the card base grew only 9%.
Those four figures say something useful for your decision: the growth is on the usage side rather than the card side. The cards already existed; what is changing is the number of merchants able to accept them, and that is a place you can take.
That has a consequence for the order described above. If your business can collect payment online, the website stops being the least ambitious first step and becomes the step that earns — which moves the internal system after it rather than before.
One precaution we repeat everywhere: have the checkout tested with both of the market’s cards before opening. Authentication journeys and error messages differ, and a checkout verified with only one goes live with half its cases never run.
GIE Monétique, 2025 annual balance sheet
What can be measured on a project, and what cannot
A software project is judged on three numbers, and none of the three is technical.
The first is time saved, for an internal tool. It is measured beforehand: how many minutes the operation the tool is to replace takes today, multiplied by how many times a day it happens. Without that prior measurement you will never know whether the project succeeded.
The second is enquiries avoided, for a website. Calls whose only purpose is information that could have been published, wasted journeys, irrelevant requests: figures your reception already knows.
The third is real usage, for an app. Not installations — which measure only your advertising — but the share of people who installed it and still open it in the second month.
What cannot be measured: the satisfaction of owning a handsome tool. It is a genuine benefit and it does not justify a spend, and a supplier building their case on it is selling you their pleasure rather than your result.
Ownership: what has to remain yours
It is the least discussed subject and the most expensive when it is badly settled, because it is only discovered at the moment of separation.
The code has to be yours, and that has to be written down. A project you paid for whose sources you cannot retrieve is a project you are renting without knowing it, at a price that will rise exactly when you can no longer leave.
The hosting, the domain name and the administrator accounts have to be in your name, with a company email address. It is the same rule we repeat across the twenty sector articles, and here it has the heaviest consequence.
Your data has to be exportable in a format readable without the software that produced it. Ask for an export before signing, not when leaving — the answer to that request will tell you more than the rest of the proposal.
And documentation is required: enough to let somebody else take over. A supplier refusing to produce it is not more competent, they are harder to replace, and those are not the same thing.
What to check before signing
The first question sorts everybody: ask which of the three categories they recommend and why. A supplier who never questions the original request is selling what you named, not what you need.
The second is about scope: what is included, what is not, and what triggers a supplement. It is the same line as in construction and it produces the same disputes.
The third is about maintenance: how much a year, what it covers, and what happens if you do not take it. A quotation with no maintenance line is an incomplete quotation, however precise it is elsewhere.
The fourth is about ownership and export, described above, and it is checked by making a concrete request rather than by reading a clause.
The fifth is a test: ask what they would refuse to build. A supplier who accepts everything does not have a method, they have an order book — and you will be the next line in it.
What we do, and what we will refuse to do
What we will refuse: building a mobile app when none of the three usage criteria is met. Saying so loses us a more profitable project, and we prefer that to delivering something nobody opens in the second month.
We will also refuse to replace a spreadsheet that works. While none of the four signs is present, custom software takes flexibility away from you in exchange for a gain you will not measure.
And we will refuse to price a project without its maintenance. A quotation stopping at delivery describes half the spend, and the half it omits is the one that lasts.
What we do: the opening question — who uses it and how many times a day — asked before any proposal; the code, the hosting, the domain and the data in your name and exportable; a costed maintenance line from the first quotation; and the prior measurement, without which nobody will know whether the project worked.
And what you should do without us this week: time the operation you want to automate, once, and multiply it by the number of times it happens in a day. It is free, it takes ten minutes, and that figure will settle the conversation better than any quotation.
Frequently asked questions
Should we start with a website or an app?
With a website, in almost every case. An app assumes an installation, so somebody who already knows you; a website answers a search made by somebody who does not. Those are two different moments and the second comes first.
When is a mobile app justified?
When there is repeated use by people already acquired, or a need the web does not cover: offline use, continuous camera use, a notification that has to arrive. If your need is not on that list, start elsewhere.
Is our spreadsheet still enough?
It is enough while none of these four signs appears: two versions of the same file in circulation, the same information entered twice, two people needing to write at once, or a need to know who changed what. At two signs, software becomes cheaper.
What does a project like this cost in Algeria?
We quote no range: we know of none that is dated and checkable, and those in circulation exist to anchor a negotiation. Ask for three quotations and compare what each excludes — that is more instructive than the totals.
What should we require on ownership?
The code, the hosting, the domain name and the accounts in your name, and an export of your data in a format readable without the software. Ask for that export before signing: the answer tells you more than the rest of the proposal.
Where do we start if we do only one thing?
Time the operation you want to automate and multiply it by its daily frequency. That figure says whether there is a project, which one, and how much it can cost before it stops being worth it.
Where we come in
Two written answers — who will use it, how often — eliminate two of the three categories. Almost nobody writes them before asking for a quote.
- We ask that before any technical discussion, and we wait for the answer.
- We price maintenance in the same document as the build.
- We tell you when a spreadsheet that works has no reason to be replaced.
A mobile application is not justified at your company without daily use, whatever budget is available.
Read next
Taking back a system nobody answers for: what can be recovered, what has to be rebuilt
Your site runs, your software runs, and whoever built them has stopped replying. A great deal of the answer is public and free.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.Artificial intelligence: what it does well, what it invents, and what you cannot hand it
Its failure mode is not breakage, it is confident error. It produces text just good enough that nobody checks it.
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.