Algeria AgencyBuilding
The month renting gets more expensive than building
Past a certain volume, buying attention every month costs more than making the thing that receives it. How to spot that moment, and what breaks if you build too early.
The two tiers below this one rent: they rent attention from platforms, month after month, and the day the invoice stops the attention stops with it. That is a perfectly rational arrangement for a while, and it stops being one at an identifiable moment.
That moment is not a company size or a revenue figure. It is the point where the same sum, spent once on something you own, produces more than it does spent every month on something you rent. A shop that takes money, an order flow that stops losing people, a card payment that works: these are paid for once and then work for free.
The trap is believing that moment arrives early. It arrives after the offer has been proven, not before — and a business that builds before proving builds something nobody wants, very neatly. It is the most expensive mistake in the whole catalogue, because it immobilises both money and six months.
This article describes how to recognise the tipping point, what a month of development really costs, what card payment has become in Algeria, why the bank file is a delay rather than a feature, and what you should own at the end.
Renting and owning are not compared in the same place
Advertising spend is rent: it buys attention for a period, and when the period ends only what you extracted from it remains. Construction spend is a purchase: it produces an object that keeps working with no further spend.
The honest comparison is therefore not "what does a site cost" against "what does a month of advertising cost". It is "what does a site cost" against "how many months of advertising would produce the same effect, and for how long". Put that way the question often has a clear answer, and it is not always the expected one.
The tipping point depends on two numbers you already have if the earlier stages were done: the volume of visitors arriving and the proportion you lose for a structural reason. A sale lost for want of online payment, a quote lost for want of a catalogue, an order lost for want of tracking — those are losses no advertising budget corrects, whatever its size.
The resulting rule is easy to state: build when the monthly structural loss exceeds the monthly cost of removing it. Before that point the budget returns more in advertising; after it, more in construction, and the gap widens every month.
Two calendars that do not set to each other
A month of advertising and a month of development do not have the same shape, and that is the first thing that surprises businesses buying both together.
A month of advertising produces something every week: numbers, a correction, a decision. It is reassuring because it is granular, and it gives the impression that work is progressing because some of it is visible every Monday.
A month of development produces almost nothing visible until the end. For four to six weeks most of the work is structure: things that cannot be photographed, on which everything photographable later depends. That is the period when clients most often ask where the project stands, and when the honest answer least resembles an answer.
That mismatch produces a predictable error: demanding the visible mid-flight. Every screen shown too early triggers an opinion, every opinion triggers a change, and a structural change halfway through a build costs several times what it would have cost before. Our rule is to show complete mock-ups at milestones agreed in advance, and nothing in between.
What a month of development costs in months of advertising
The right unit for judging a project is not the dinar, it is the month of advertising the same dinar would have bought. That framing changes most trade-offs, and it changes them in both directions.
It makes some features obviously absurd. A customisation option costing the equivalent of three months of campaign, on a shop receiving two hundred visitors a day, will not pay for itself for years — and will probably be rebuilt before it does.
It makes others obviously mandatory. An order flow losing half its buyers at the payment step costs, every month, more than fixing it once would. That calculation is done with your own numbers and takes half an hour; it requires no technical expertise.
It is also the framing that lets us say no to what we sell. When a client asks for a mobile app while their site has no decent product page, the equivalent in campaign months makes the conversation short and impersonal — which is exactly what a decision that size needs.
Card payment changed scale in a single year
The most common objection to online payment in Algeria — "our customers do not pay by card" — describes a reality that stopped being true recently, and far faster than most businesses have registered.
The total of electronic card operations cleared a step in one financial year. A rise of that order on an already broad base is not a start-up effect: it is a change of habit, and changes of habit are not reversed.
What that means for a business is precise. The customer who hesitated to type a card number three years ago has now done it several times, elsewhere, without incident. You no longer have to teach them to pay online, which was the real cost of going first.
One reading caution, because the figure is often quoted wrongly: this total covers all card operations, cash withdrawals included, not just internet purchases. It is the rising tide, not the share that concerns you — that comes in the next section, and it is smaller and much faster.
GIE Monétique, 2025 annual balance sheet
The growth is not where it is assumed to be
The headline figure hides what matters, and what matters appears once the indicators are separated. Over the same year, the number of card transactions online, the number of online merchants and the amount paid online did not grow at the same rate — the spread between them is more than four to one.
That spread says something precise: it is not only payments multiplying, it is baskets growing. People are no longer testing online payment on small sums, they are making real purchases with it.
This is the most important figure in the article for a business selling at a high price point. The objection "our customers would never buy something at that price online" had a basis five years ago; today it describes behaviour from five years ago.
The third indicator deserves reading separately. The number of online merchants is growing markedly more slowly than the amount spent, which means demand is growing faster than supply. That is the most favourable configuration a market can present, and it never lasts very long.
GIE Monétique, 2025 annual balance sheet
The bank file is a delay, not a feature
Accepting cards on a site assumes two very different things: a technical integration, which is ordinary predictable work, and a file with the institutions, which is neither.
We publish no average duration for that file, and the refusal is deliberate. Each file moves at its own speed, no institution publishes processing statistics, and the only figures in circulation are agencies’ assertions about their own past files. Quoting ours would present unverifiable experience as data; quoting a competitor’s would be worse.
What can be said honestly is the shape of the delay rather than its length. It does not depend on the complexity of your site, it does not accelerate by paying more, and it starts when the file is complete — not when it is submitted. The only variable you control is therefore completeness at first submission.
The practical consequence governs the whole schedule: the file goes first, before development, because it is the only element of the project whose duration does not depend on us. A finished site waiting for its file is a site that does not sell, and that wait is entirely avoidable.
What breaks when you build while the ads are running
This tier does both at once, and that is its point: stopping acquisition during a three-month build means switching off the only channel producing revenue in order to build the one that will. Doing both together does have a cost, though, and it is better known in advance.
The first problem is the moving target. A campaign is corrected from what visitors do on a page; if the page changes every week the measurements no longer compare, and two months of data become unusable. So we freeze landing pages during measurement periods, even when an improvement is ready.
The second is traffic sent to a building site. A half-rebuilt page converts worse than the old version, and the budget spent during that period pays to show an interior under works. The rule is to switch over all at once, never in visible pieces.
The third is human, and the most frequent. The same person, on the client side, approves the advertising visuals and the site screens. During a build that person becomes the bottleneck for both projects at once, and the project slows for a reason nobody budgeted.
The catalogue is the real project
Every online-shop demonstration shows a full shop. The catalogue is already there, the photographs are taken, the descriptions are written, the stock figures are right. It is the part nobody sells and everybody has to do.
The real work is counted in products, not in features. Three hundred references to photograph, describe, categorise, price and keep current represent a volume of work that often exceeds the development itself, and it falls on the client because only they know their products.
It is also what decides the opening date. A technically finished site with forty products out of three hundred does not open: it gives the impression of a shop in liquidation. We would rather open one complete category than three half-filled ones, and that decision is taken at the start, not the end.
One way to make the load bearable: start with the twenty products that make most of the revenue, open with those, and fill in the rest afterwards while the shop sells. It is less satisfying than a complete catalogue on day one, and it brings the first order forward by several months.
An app is not a website with an icon
The request for a mobile app almost always arrives at this level, and it deserves a question before a quotation: what will the app do that the site cannot?
There are real answers. A notification the customer agrees to receive, an offline use, a hardware access — camera, location, code reader. Those three cases justify an app, and nothing else justifies one as clearly.
There is also a very common false answer: "to be on the customer’s phone". You already are, in their browser, without them having to install anything, grant permissions, or find storage. Each of those three steps turns away a share of people, and for a first visit they turn away almost all of them.
The rule we apply: an app is built for customers who come back, never for those you are trying to acquire. If the problem is being found, an app is the most expensive answer to a question it does not address.
What you should own at the end
A build of this kind produces things that will outlast us, and the list should be written before starting rather than demanded on the way out.
The source code, with its history, in a repository in your name. Not an archive sent at delivery: the history is what lets another supplier understand why something is done the way it is, and that is half the value.
The domain name, the hosting, the ad accounts, the platform logins, the merchant account: all created in your name from day one, not transferred on the last day. An end-of-engagement transfer is an operation that regularly fails, and it fails at the worst moment.
Finally the data: products, orders, customers, exportable in an open format without asking us. A database that can only be extracted by going through the supplier is a database you own on paper only, and it is the commonest form of dependency in this trade.
The "while we are at it" trap
Every construction project attracts additions. They arrive with the same phrase — "while we are at it" — and they are individually reasonable, which is precisely the problem.
Each addition costs more than its isolated estimate, because it has to be designed, built and tested, and above all because it delays everything that comes after. A build that slips six weeks also costs six weeks of the revenue the site would have produced.
The discipline is keeping a separate list rather than refusing. What does not go into the first version is written there, dated, and picked up after launch — at the moment when it will be known, with figures, which of those additions really deserve doing.
Most of those lists empty themselves. Three months after opening, half the indispensable additions have stopped being indispensable, and that half is the budget honest project management saves without ever appearing anywhere.
What we do, and what we refuse to do here
At this level we build — site, shop, application, payment integration — while acquisition keeps running, and we coordinate the two calendars so they do not destroy each other. The bank file goes first, the catalogue starts in parallel, and the switchover happens in one move.
What we refuse is plain: we do not start a build while the acquisition numbers say the offer has not been proven. If a properly run campaign has not produced enquiries at a sustainable cost, a shop will fix nothing — it will simply make the same problem more expensive and slower to correct.
We also refuse to announce a go-live date that depends on a bank file. We give two dates: the one the site will be ready, which binds us, and the one payment will work, which does not depend on us and which we therefore do not promise.
Finally, we do not build a mobile app for a need a website meets. That costs us the largest quotation in the catalogue and it is the only defensible advice: an app developed to acquire customers you do not have yet is a project paid for twice, once to be built and once to be abandoned.
Frequently asked questions
Can advertising continue during development?
Yes, and that is the point of this tier. We simply freeze the measured pages during measurement periods and switch over in one move rather than in visible pieces.
How long does an online shop take?
The technical part is predictable and can be planned. What decides the real date is the catalogue — photographs, descriptions, prices, stock — and the payment file, whose duration does not depend on us.
Do we really need card payment to sell?
No, cash on delivery sells perfectly well. What the card changes is the average basket and refusals at the door: a customer who has already paid does not cancel.
Who photographs the products?
You or us, and it is a line to budget explicitly. It is the first underestimated job in every shop project, and the first reason an opening slips.
Do we own the site completely?
Yes: source code with its history, domain, hosting, accounts, exportable data, all created in your name from day one. Nothing is transferred at the end because nothing was ever ours.
What if we want to change supplier after delivery?
You leave with all of it, at no cost and with no negotiation. A supplier who makes leaving expensive has engineered their own indispensability, which is a way of holding a client without satisfying them.
Where we come in
Building while acquisition runs costs more than building first, and it is almost always the right order: a shop with no visitors learns nothing.
- We separate in writing what we hold from what a bank file decides.
- We keep acquisition running through the build instead of suspending it.
- We price a site before an app, and say what the second one adds.
We will not take over maintenance of a build made elsewhere without reading all of it first, and that reading is billed.
Read next
The decision queue: what the project is waiting on at your end, and what each wait costs in weeks
A project at this level almost never waits on code. It waits on a decision, a piece of data, or a photograph nobody has taken yet.Integrating CIB and Edahabia online payment
Cards are no longer the constraint: there are 21.9 million of them. What is missing is merchants who accept them.E-commerce: what you are shown is the shopfront, what you are buying is the back office
Every demonstration shows the shop. All the cost and all the risk sit behind it, in the part nobody draws.
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.