Short answer. A real-time dashboard is not a query on the till’s database every time the owner opens the screen; it is a chain: every sale, cancellation, delivery or payment becomes an event in a queue; one definition per figure, written once in the code with the accountant, says what “today’s revenue” means, with or without tax, returns deducted, cut-off time; counters per shop, product and hour are incremented when the event arrives and read from memory, never recomputed; the screen shows the time of the last update next to every figure; a server-to-phone stream pushes the news and reconnects by itself; at night everything is recounted from the events so that today’s figure and the month’s comparison share one definition; and WhatsApp alerts on thresholds and silences replace watching the screen. Ten weeks, the first without code, devoted to the ten figures and their definitions.
This guide is for the owner of several shops who receives a file on Monday and learns on Thursday that a till was down, the founder settled in France who wants to see their sales in Algeria on their phone without calling, the distributor whose pre-sale and accounting figures never meet, and anyone reading “real-time dashboard” in a quote without knowing what lies behind it. It does not compare business intelligence tools, which the guide on BI in Algeria does; it describes what gets built so that the figure is right, fresh and readable on a phone.
What the figures say
The owner’s phone has become a sufficient screen. According to DataReportal’s Digital 2026 report for Algeria, published on 8 November 2025, the country had 37.8 million internet users in October 2025, 79.5 % of the population, and 55.6 million mobile connections at the end of 2025 according to GSMA Intelligence; the median mobile download speed measured by Ookla reached 41.21 Mbps, up 65.5 % over the twelve months to August 2025, and the median fixed speed 37.86 Mbps. On 17 May 2026 a communiqué from the Ministry of Post and Telecommunications, relayed by Radio Algérie, announced that Algiers entered the global top 50 of Ookla’s city ranking for mobile internet, at 48th against 116th in September, with a download speed of 163.31 Mbps; that is Algiers, on Speedtest, after the 5G launch in late 2025, and other testers report far lower national medians. What this imposes: the owner’s screen must open fast on good 4G in Algiers and stay readable on a mediocre network in a wilaya, which is decided in the architecture, not in the mock-up.
The technique behind real time is ordinary and documented. Server-sent events, described by Google on web.dev, push updates to the browser over an ordinary HTTP connection, reconnect by themselves after a drop, with a default delay of about three seconds, and send the server the identifier of the last event received so it can resume; that is exactly what a screen that reads and does not talk needs, where WebSockets, bidirectional, serve messaging and games. On the database side, PostgreSQL’s documentation describes refreshing a materialised view that “completely replaces the contents”, with an option that avoids blocking reads provided a unique index exists; that is the tool for comparisons recounted at night. For the day’s counters, extensions such as TimescaleDB describe continuous aggregates that recompute only the changed time buckets, according to the vendor’s documentation; we get the same effect, more simply, with counters incremented on the event.
The rest is Algerian and appears in no report: the Windows till that exports a file at closing, the owner who runs six shops through WhatsApp calls, the cut-off at 11 pm in one shop and midnight in another, the Monday file an employee prepares on Sunday. We found neither a study on the acceptable delay of a figure nor a measure of dashboards in Algeria; we observed it: a figure the owner does not believe is not looked at, and a figure they believe is looked at ten times a day. This guide says how you get the second.
The life of a figure, from the sale to the owner’s phone, in six moments
The dashboard is not described by its charts but by what happens to a sale, from a shop’s till to the owner’s phone, and by what keeps the figure from going wrong on the way.
The event is born when a sale is taken at the till or in the app: time-stamped, with the shop, the source and an idempotency key, placed in a persistent queue, never counted twice even if the till resends the same receipt after a drop, by the mechanism the guide on the offline app describes; a cancellation or a return is a negative event through the same queue, not a deleted row. The definition is the moment that avoids the two figures: “today’s revenue” is written once in the code, with the accountant, with or without tax, returns deducted, cut-off time, time zone, shops included, and versioned; the till, the owner’s screen and the accountant’s report read the same definition. The aggregate is a counter per shop, per product and per hour, incremented when the event arrives; when the owner opens the screen, nothing is recomputed and the database serving the tills is not touched.
Cache and freshness: the screen reads counters from memory and shows, next to every figure, the time of its last update; a figure without a time is a figure you cannot tell is old. Delivery pushes new counters from the server to the phone through an event stream that reconnects by itself after a network drop and resumes from the last event received; the owner’s screen is an installable app, described in the PWA guide, which shows the last known counters even offline, with their time. The alert replaces watching: a stock threshold crossed, an unusual gap with the same day last week, a till that has sent nothing for an hour in the middle of the day, and a WhatsApp message leaves for the owner with the figure and the link, through the platform described in the guide on the WhatsApp agent.
The real-time dashboard, in five layers
Behind the six moments, five layers, and the middle one is the only one really built.
Sources are the tills, the field app, the ordering portal, the WhatsApp agent, accounting and the bank; each has its connector, API, file or database read, following the guide on integrating existing software, and each emits events in the same format. Events live in a persistent queue with timestamp, idempotency key, source, and corrections as events in their own right; this is the truth from which everything is recounted. Aggregates and definitions are the real deliverable: counters per shop, product, hour and customer, versioned definitions with one owner per figure, and a nightly recomputation from the events that checks the day’s counters have not drifted.
Delivery is a read API, a server-to-phone stream, a cache, and the owner’s installable app, which opens in under a second on an ordinary mobile network because it asks only for counters already prepared. Alerts and reading: thresholds per shop and product, gaps, silences, WhatsApp messages, and comparison with the same day last week rather than yesterday; the owner does not watch the screen all day, the screen comes to them when needed. The layers below decide whether the till slows down; the layers above decide whether the owner still looks in three months. The same dashboard serves the founder running things from France, described in the guide on the shop managed remotely.
«A dashboard that queries the till’s database at every opening is a report; the dashboard is the event, the definition, the counter and the time displayed.»
A worked example
An example on usage assumptions, with mechanics that are not assumptions: a chain of six shops, an owner in Algiers, an external accountant.
Six shops each with its till, plus an ordering portal for retailers; every sale, cancellation and order becomes an event within seconds, through the till’s connector or the app. Fifteen seconds between the sale taken and the figure updated on the owner’s phone: this is our assumption, which depends on the till’s connector and the network, and it is what the pilot measures on real shops; a till that exports only at closing gives a figure current in the evening, and the screen says so with its time. One definition of revenue instead of three: the till, the screen and the accountant say the same thing at the same cut-off time, and the Monday report, the one an employee prepared on Sunday, stops after the first month of reconciliation.
Under one second to open the screen on an ordinary mobile network is the result that depends on no assumption: counters are read from memory, no heavy query touches the production database, and the installed app shows the last known counters before the network even answers. What the example shows: with six shops and an owner opening the screen ten times a day, the “query on opening” dashboard runs sixty heavy queries a day on the database serving the tills, at peak hours; the counter dashboard runs none. The assumptions to check at home: how many sources, which export mode for each till, how many figures the owner really looks at; the project’s first week answers them.
Six owner figures and the freshness that suits each
Not everything needs to be real time, and wanting everything in real time costs a lot for nothing; freshness is decided figure by figure, by the decision it triggers.
Today’s revenue per shop wants a few seconds to a minute: it is the figure the owner looks at ten times a day, and it is a counter incremented at every sale or cancellation event, with the cut-off time in the definition. Critical stock is content with a few minutes: a counter per product and per shop, a threshold per product, and an alert when it is crossed, because nobody watches a stock screen. Takings against the till are checked at the end of the day: that is the reconciliation between sale events, payment terminal and statement described in the till guide, and it lists the gaps rather than hiding them.
Customer balances want the hour: invoice and payment events arrive from accounting or the B2B portal, described in the dedicated guide, and a counter per customer says who exceeds their credit. Deliveries in progress want a few seconds: statuses are pushed by the drivers’ app described in the delivery platform guide, a counter per status and per zone, an alert on delay. The week and month comparison is recounted at night, in a materialised view refreshed from the events with the same definition as today’s figure; that is what lets you say “this Tuesday against the Tuesday a week ago” without the two figures having been counted differently.
Six situations that make the owner doubt the dashboard
Six situations we see on the dashboards we take over, and what the architecture does against each.
Two screens, two figures is the first cause of abandonment: the till says 412,000 dinars, the screen 398,000, the accountant a third figure, and the difference comes from three definitions, tax, returns, cut-off time; the defence is one definition per figure, written in the code, versioned, read by every screen, and a monthly reconciliation with the accountant that corrects the definition when it is wrong. The dashboard that slows the till: at 6 pm the sellers wait because the owner opened their screen and the screen ran a query on the production database; counters updated on the event and read from memory, zero heavy query. The figure wrong at 2 am: the till’s day ends at 11 pm, the screen’s at midnight, the server’s in universal time; cut-off time and time zone written in the definition, and the owner’s day is their shops’ day.
The page that spins on 3G: four seconds of waiting in a wilaya and the owner closes it; installable app, cached counters, light screen, and “updated … ago” visible even offline. The cancelled sale that stays counted: a return at the till does not bring the figure down; the cancellation is a negative event through the same queue, and the nightly recomputation from the events catches what would have drifted. The owner who stops looking: the screen is beautiful and nobody opens it after three weeks; WhatsApp alerts on thresholds and silences, ten figures at most, and the comparison with the same day last week, which is the only one that means something on a Friday. The first costs trust, the others cost the till’s speed or the owner’s attention, and none is fixed in the layout.
«Two figures are fixed with a definition, not with a chart.»
Seen elsewhere: web.dev, PostgreSQL, Ookla, and what transposes
Three public texts say the essentials. Google, on web.dev, describes server-sent events: an ordinary HTTP connection, updates pushed one way, automatic reconnection with a default delay of about three seconds, and the identifier of the last event sent back to the server to resume; what transposes is that an owner’s screen needs neither WebSockets nor special infrastructure, it needs a stream that reconnects by itself and a server that knows how to replay what was missed, and that second point is the builder’s job. PostgreSQL describes the materialised view whose refresh replaces all the contents, with an option that does not block reads if a unique index exists; what transposes is to keep that tool for comparisons recounted at night and never make it the source of today’s figure.
Ookla, through DataReportal and the ministry’s communiqué, says the Algerian mobile network has improved a lot, especially in Algiers; what transposes is that the screen can be rich on good 4G, and what does not transpose is Algiers’ speed in a wilaya on a peak evening, hence the installable app, the cache and the freshness time displayed. What these texts do not say: which ten figures your owner really looks at, and with which definition your accountant computes them; the project’s first week, not a documentation, answers that.
The rules of a dashboard that keeps being looked at
Six rules, written in the first week and reread at every figure added. Ten figures at most, each with its owner, its definition and its useful freshness; a forty-figure dashboard is looked at by nobody. One definition per figure, written in the code, with the accountant, versioned, and the same for the till, the screen and the report. Counters update on the event, never on opening the screen, and the production database is not touched by reading. Every figure shows its time; a figure without a freshness time is not displayed. The night recounts everything from the events, and a gap between the day’s counter and the recomputation is an alert, not a detail. Alerts replace watching: thresholds, gaps, silences, by WhatsApp, and no more than a few a day, or they stop being read.
A seventh rule concerns the specification: “real-time dashboard” is not a requirement, it is a sentence; the requirement reads “today’s revenue per shop is updated within the minute following the sale, with its written definition and its time displayed; the screen opens in under a second on a mobile network; no query from the screen touches the tills’ database; figures are recounted every night from the events; gaps with accounting are reconciled every month”, and it is checked at acceptance, as the guide on the specification recommends. A quote that prices “a dashboard” without saying where the events come from or who writes the definitions has priced charts.
Six companies, what goes on the owner’s screen
Six companies we often equip, and for each the figures chosen in the first week.
- The chain of shops. Today’s revenue per shop, average basket, critical stock, takings against the till in the evening; alert when a till goes silent in the middle of the day.
- The distributor with pre-sellers, described in the dedicated guide. Orders taken per round, visit rate, balance per retailer, deliveries in progress; alert on a retailer exceeding their credit.
- The founder in France. The same figures as the local manager, on the same screen, with WhatsApp alerts at Paris time; the comparison with last week instead of the evening call.
- The clinic or practice. Today’s appointments, no-show rate, procedures invoiced, takings; alert when tomorrow’s appointments are not confirmed.
- The delivery platform. Parcels in progress per status and zone, delays, returns, cash on delivery collected against declared; alert on delay and on collection gap.
- The SaaS sold to companies, described in the guide on multi-tenant SaaS. One dashboard per customer on the same platform, counters per tenant, shared definitions; the founder sees everyone’s usage, each customer sees only their own.
The 2027 calendar
The calendar is that of a ten-week dashboard, the first week without code and the last two of pilot on two real shops.
Week 0 to 1 writes the definitions: ten figures at most, each with its definition written with the accountant, its useful freshness, its owner and the threshold that triggers an alert; it is the week that decides whether the owner will believe the screen. Week 1 to 2 connects the sources: tills, app, portal, accounting, each through its connector, each emitting events in the same format. Weeks 2 to 4 build the events and counters: queue, idempotency, cancellations as negative events, counters per shop, product and hour, nightly recomputation from the events, and a test comparing the two at every release. Weeks 4 to 6 build the screen and delivery: the owner’s installable app, cached reads, server stream with reconnection and resume, freshness time displayed, and a test on a degraded mobile network.
Week 6 to 7 sets the WhatsApp alerts: thresholds per shop and product, unusual gaps, silent till, with the figure and the link in the message. Week 7 to 8 reconciles the screen’s figures with the accountant’s over a full month: gaps are explained, definitions corrected, and that is what makes the screen credible. Weeks 8 to 10 are the pilot on two shops, with the real delay measured between sale and screen, then the switch of all six; the Monday report stops when the owner no longer asks for it. What a year of this dashboard then costs, servers, messages and updates included, enters the budget described by the guide on keeping an app alive.
What makes a dashboard fail
The dashboards we take over almost always fail for one of these reasons.
- The query on opening. The screen queries the tills’ database every time; the owner looks, the sellers wait.
- Three definitions of the same figure. The till, the screen and the accountant do not say the same thing, and the owner believes nobody any more.
- No freshness time. Yesterday’s figure displayed as if it were live; the day the owner notices, the screen is dead.
- The deleted cancellation. The return deletes a row instead of adding an event; nothing is recounted, everything drifts.
- Forty figures. Everyone wanted theirs; nobody looks at any.
- No reconciliation with the accountant. The screen lives its life, the books theirs, and the month’s gap is found at year end.
- The beautiful chart on a heavy page. Four seconds on a wilaya’s 3G, and the owner goes back to WhatsApp calls.
Frequently asked questions
The questions we receive from owners, founders settled in France and accountants.
- What does real time actually mean for an owner?
- That today’s figure updates within the minute following the sale, with its time displayed, without the owner refreshing or the till slowing down. The rest, stock, balances, comparisons, has its own freshness, from a few minutes to overnight, decided figure by figure according to the decision it triggers.
- Why do the till, the screen and the accountant never give the same figure?
- Because they apply three definitions: with or without tax, returns deducted or not, a day ending at 11 pm, at midnight or in universal time. The defence is one definition per figure written once in the code with the accountant, read by every screen, and a monthly reconciliation that corrects it when it is wrong.
- Will the dashboard slow the till?
- Not if it is built on events and counters: the till emits an event, the counter increments, and the screen reads the counter from memory without touching the production database. A dashboard that queries the till’s database at every opening slows it, and it is the first defect we fix.
- My Windows till has no API. Can we still get the figure?
- Yes: most export a file at closing or every hour, and a connector reads it and turns it into events; the figure is then current at every export, and the screen says so with its time. When the till is replaced or connected directly, the connector changes and the screen does not move.
- And for an owner who lives in France?
- The same screen, the same installable app, the same counters; WhatsApp alerts arrive at Paris time, and the comparison with the same day last week replaces the evening call. It is the case the guide on the shop managed from France describes from the owner’s point of view.
- How long to build the dashboard?
- Ten weeks, the first without code to write the ten figures and their definitions with the accountant, two weeks of pilot on two shops, and one week of reconciliation with accounting that makes the screen credible. The connector for a till without an API is what most often stretches the calendar.