From Storefront to Doorstep: How Algonize Gives Multi-Branch Businesses One Real-Time Command Center

TL;DR: Algoramming designed and built Algonize, an all-in-one platform that collapses a shop's scattered tools into a single real-time command center. From one login, a multi-branch business runs its storefront, checkout, inventory, staff, delivery riders, loyalty, and billing across the web, desktop, and mobile, while every branch and device stays in sync through one backend. The product is three apps built on one core: a Flutter merchant Portal, a Flutter customer ordering app, and a Flutter rider app for delivery, all backed by a Node.js and PostgreSQL platform, a custom ESC/POS printing package, and a companion Chrome extension that lets the web POS print to a local thermal printer, something browsers cannot normally do. This study walks through the hardest problems we solved: multi-tenant data isolation, web-native thermal printing, a self-enforcing database, and tracing a single order from storefront to doorstep in real time. Want one for your business? Talk to Algoramming.

---

At a glance

---

The challenge: five disconnected tools, one blind owner

Small and mid-sized businesses rarely fail for lack of effort. They fail because their tools do not talk to each other. A typical owner ends up juggling one app for the cash register, a spreadsheet for stock, a notebook for customer credit, a separate service for delivery, and no single number that tells them whether today was profitable. Each tool assumes a different device, a different login, and its own definition of a "sale." Add a second or third branch and those gaps harden into daily firefighting.

Algonize had to do several things that are individually common but rarely solved together and well:

• Run the same business on any device the merchant already owns, from a plain browser to a desktop to a phone, with no special hardware.
• Handle a real point of sale: fast checkout, product variations, correctly decrementing stock, discounts, VAT, service and delivery charges, and a printed receipt on a cheap thermal printer.
• Support more than one business per owner, each with multiple branches and staff, isolated so one tenant can never see another's data.
• Reach past the counter into online orders, rider-assigned delivery with live tracking, loyalty points, promo codes, and a subscription that gates how much of the platform a merchant can use.
• Keep every branch, device, and actor, including the rider on the road, in sync through one backend and one source of truth.

The single most stubborn requirement hid inside that list: a web-based POS has to print to a thermal receipt printer on the local network, and a browser is not allowed to open a raw network socket. That one sentence produced weeks of the most interesting engineering in the project.

What Algonize does

Everything below runs against one backend and one data model, so a sale, its stock impact, its ledger entry, its receipt, its delivery, and its loyalty points are a single connected flow rather than six disconnected records.

The ecosystem at a glance

Algonize is not one app. It is a small constellation of applications that share a backend and a data model. Solving the business problem meant building each piece to a production standard and making them agree on every field. Three of those pieces are full Flutter apps for three different people: the owner or cashier, the customer, and the rider.

A useful way to read the rest of this study: the backend defines the truth, the three apps consume it, and the printing package plus the browser extension exist purely to defeat one specific limitation of the web platform.

The journey: from storefront to doorstep

The name of this case study is not marketing language, it is the actual data path. A single order travels from a customer's screen to their doorstep, and the merchant watches every step move in real time from one dashboard, while the rider carries the last leg on a phone. Because it all runs on one backend, there is no reconciliation between systems and no "which screen is right" argument at the end of the day.

Architecture: one backend, three honest clients

The Portal, the customer app, and the rider app are all Flutter applications and deliberately share the same conventions, so a developer who knows one can read the others. Each uses Riverpod for state, go_router for navigation, get_it as a service locator, Hive for local storage and token caching, and a hand-written HTTP client rather than a heavy networking SDK. Every feature is a self-contained module split into model, provider, api, and view folders, and every entity serializes through the same pattern: a plain data class, a companion extension file for copyWith and JSON, and a private key class so JSON field names live in exactly one place.

That discipline matters more than it sounds. Because the three clients agree on the shape of a sale, an order, an inventory item, and a rider, an order placed in the customer app deserializes cleanly in the merchant Portal and again in the rider app, expanded relationships and all. The Portal is the full operating system with roughly twenty-six modules. The customer app is a trimmed consumer client, and the rider app is a focused delivery client, both carrying many of the same models purely so they can read what the backend sends back. This shared-convention discipline is the same approach Algoramming applies across its cross-platform product work.

The backend is a modular monolith: a single Express process, a single PostgreSQL connection pool, and about thirty feature modules that each follow the same five-layer vertical slice of routes, controllers, services, database access, and interfaces. There is no ORM. Data access is hand-written parameterized SQL, which turned out to be a deliberate advantage rather than a shortcut, because a large share of the platform's logic lives inside the database itself.

The multi-tenant model that keeps businesses apart

Multi-tenancy is where a business platform either earns trust or quietly leaks it. Algonize uses a shared-database, shared-schema, row-scoped model built on a clear hierarchy:

• A merchant is the human account, the person who logs in.
• A business is the tenant. It owns a catalog, a currency, and a per-tenant configuration.
• A branch is a location under a business, with its own opening hours and its own financial defaults for VAT, service charge, delivery charge, and employee charge.
• A contributor is the membership record that binds a merchant to a specific business and branch with a role. This is how a single owner reaches several businesses and how staff are added to one.

Almost every domain table carries a mandatory business identifier, and often a branch, with cascading foreign keys, so a tenant's data is scoped at the query layer in each module. When a merchant signs up, a single database transaction provisions their entire starting world: the merchant record, a first business, a "Main Branch," an owner contributor, and a free-tier billing record with a fifteen-day cycle. The merchant lands in a working system, not an empty one.

A detail worth stealing: each business gets its own PostgreSQL sequence for invoice numbers, created on demand, so every tenant has an independent, gapless sale and order counter. Two businesses can both hold invoice number one on the same day and never collide.

On access control, we describe the system precisely rather than generously. Roles such as Owner, Admin, Manager, and Operator are modeled on the contributor record and enforced in the client experience, where the Portal restricts which screens and actions each role can reach. The API layer itself uses tiered token verification that separates a customer, a merchant, a rider, and a super admin, so the rider app can only ever see and act on the deliveries assigned to it. Tightening fine-grained role checks down into the API middleware is a known, scoped next step rather than a claim we make today.

PostgreSQL as an application engine, not just a table store

The decision that shaped the backend most was pushing correctness-critical logic into the database as triggers and functions. Three examples show why that paid off.

Stock that cannot oversell, even under concurrent checkout. Before a sale or order is written, a database trigger validates inventory. It computes the net change per line item, takes advisory locks in a deterministic order so two simultaneous checkouts cannot deadlock, checks the requested quantity against a live stock-usage view, treats an untracked item as unlimited, and raises a readable error if a line would go negative. Because this lives in the database, it holds no matter which client or which device fired the request.

A double-entry ledger that writes itself. Every sale and order automatically generates balanced ledger transactions through triggers, and updates to those documents adjust the ledger to match. The ledger records financial and non-financial legs separately, which is what lets the platform answer both "how much money moved" and "how much stock moved" from the same records. A stock-usage view derived from that ledger then feeds both the oversell check above and the dashboard's top-selling analytics.

Loyalty that provisions on day one. The moment a business is created, a trigger writes its default loyalty configuration, so points can be earned and redeemed without any extra setup step.

Putting this logic in PostgreSQL means it is enforced once, close to the data, and cannot be skipped by a client that forgot to call the right endpoint.

Real-time notifications without a fragile side service

Merchants, customers, and riders need timely push notifications: a new order, a status change, a rider assignment, a delivery update. Rather than bolt on a separate queue, the backend uses a database-native outbox pattern.

When a notification row is inserted, a trigger fires a lightweight PostgreSQL NOTIFY carrying only the row id. A dedicated long-lived listener connection, kept separate from the shared pool so it is never starved, receives that signal and dispatches the push through Firebase Cloud Messaging. Two safety properties make it trustworthy. First, a periodic sweep re-scans for any notification that was never dispatched, backed by a partial index, so nothing is lost if the listener was briefly down. Second, dispatch is idempotent through a "dispatched at" stamp, so the live signal and the sweep can never send the same push twice. Dead device tokens are pruned automatically, and delivery batches respect the messaging provider's limits. The result is real-time delivery with an at-least-once safety net and exactly-once behavior in practice.

Delivery done right: the rider app

Most POS products stop at the counter. Algonize follows the order all the way to the door, and it does that with a third Flutter app built specifically for the person on the road. The rider app is small on purpose. It does five things and does them cleanly, against the same backend and the same data model as the Portal and the customer app.

• A live delivery queue. The rider opens the app to the list of deliveries assigned to them, pulled from a rider-scoped endpoint that only ever returns their own work. Each card shows the customer, the address, the order contents, and the money side of the job at a glance.
• One-tap navigation. Every deliverable order carries the customer's delivery latitude and longitude, so the rider taps once to hand the destination straight to their phone's maps app and start driving. No copy-pasting an address, no guesswork on the last hundred meters.
• Collect-first cash prompts. For cash-on-delivery orders the app surfaces the exact amount to collect, computed from the order total minus any advance already paid, so the rider knows the number before they knock. A cancelled delivery carries a clear termination message rather than a silent status flip, so there is no confusion at the door.
• Status updates that move the whole system. As the rider works, they advance the delivery through the shared status pipeline, and because that write lands on the one backend, the merchant's dashboard and the customer's tracking screen update at the same moment.
• An honest earnings dashboard. The rider's own statistics screen shows total deliveries, completed deliveries, and delivery earnings, with a transaction bar chart and a calendar view so a rider can see a day, a week, or a month at a time.

The status pipeline is the shared vocabulary that keeps three apps agreeing on one order. An order is created, works its way through preparation, waits for a rider, goes out for delivery, and completes, with cancelled and refunded as honest exits. Each transition is one write that every screen respects.

The hard problem: printing a receipt from a web browser

Here is the requirement that drove the most original work in the ecosystem. A merchant should be able to run the POS in a browser tab and print a receipt to the thermal printer sitting on their counter, which is reachable only as an IP address and a port on the local network. The obstacle is fundamental: for security reasons, a web page cannot open a raw TCP socket. Thermal printers speak raw ESC/POS bytes over exactly that kind of socket, at the common 58mm, 72mm, and 80mm paper widths. The web platform and the printer have no common language.

Algoramming solved this in two coordinated pieces.

A universal printing package. The team built flutter_esc_pos_network_universal, a Flutter package with a single printing interface that behaves identically on every platform. It uses a compile-time platform split: on desktop and mobile it opens a real socket through Dart's native networking, and on the web it routes the same bytes to a browser bridge. Callers write one line of code and never think about the platform underneath. The package can also rasterize an entire receipt widget into an image and print that, so a richly formatted receipt looks the same on paper as on screen.

A companion Chrome extension as the bridge. Because the browser cannot hold the socket, a small Manifest V3 extension called Local TCP does it by proxy. The extension itself does not touch TCP either. It relays print requests, through a content script and a background service worker, to a tiny Node.js native messaging host installed on the machine. That host is the only component that opens a real socket to the printer at its IP and port, writes the ESC/POS bytes, and reports the result back up the chain. The web POS builds the bytes, posts them to the extension, and gets a success or an error, exactly as if the browser had printed directly. The extension and its native host are open source in the Local TCP repository on GitHub, and a short setup walkthrough is on YouTube.

That design surfaced a genuinely subtle platform trap. On recent macOS versions, local network access is tied to the code identity of the executable that opens the socket. A custom, unsigned helper binary was silently denied, showing "no route to host" even though the printer answered a ping. The fix was to run the helper through the system's own recognized Node runtime, which the operating system already trusts for local network access, and to wire the installer to point at that runtime by absolute path. Several other realities of the browser world were handled the same practical way: the Manifest V3 service worker can be shut down when idle, so print requests are self-healing and re-dial the printer if a previous connection was reclaimed; concurrent receipts are serialized per connection so two jobs never interleave their bytes; and a sleeping Wi-Fi printer is given a short, bounded retry window before a real error is surfaced. The whole bridge is guarded by an origin allowlist so only trusted web apps can drive it.

The engineering war story: making cheap thermal printers behave

Getting bytes to the printer was only half the battle. The other half was getting a low-cost thermal printer to render those bytes as a clean receipt instead of a page of garbage. This was the kind of problem that only real hardware reveals, and it produced a sequence of fixes worth documenting because each one taught a general lesson.

The symptom was maddeningly specific. A plain text test print came out perfectly, while the actual receipt printed a clean top and then dissolved into random characters. Because the text test worked, the transport and the printer were fine, which pointed the investigation squarely at how the receipt image was being encoded and streamed. The team added a deliberate diagnostic that printed a known-good text line before the image, so every test could instantly tell an image-encoding fault from a transport fault. From there the root causes came out one at a time.

• The bitmap was too wide. A receipt laid out at the printer's logical width was being captured at the device's pixel ratio, producing an image two to three times wider than the print head. An over-wide raster knocks the printer out of image mode and it prints the overflow as text. The fix was to clamp the captured image to the exact dot width of the paper before encoding.
• A release-only crash from the wrong thread. Generating the printer bytes on a background isolate lost a capability profile across the isolate boundary in release builds, something that never showed up in debug. Moving generation onto the main thread made release behave like debug.
• The image command itself desynced. The legacy column-mode image command frames each row as its own sub-command, and on real devices that per-line framing drifted, so the printer fell out of image mode mid-stream. Sending the whole bitmap as one image command removed the per-line seams and the drift.
• The chunking dilemma. This was the trap that reversed itself. Splitting the byte stream into small chunks with pauses, a habit from serial and USB printers, actually broke image commands over Wi-Fi, because a forced gap can land in the middle of an image command and abort it. So the team sent the whole ticket as one continuous write, trusting TCP flow control. That fixed some printers and broke others, because the cheapest printers advertise a large network receive window while having a tiny physical print buffer, so a single large write overran the buffer and corrupted the tail. The stable answer was in the middle: paced writes in modest chunks with small delays and a brief settle before disconnecting, sized to respect the printer's real buffer rather than its advertised window.

The lasting lesson: a thermal printer's stated capabilities and its actual behavior are two different things, and the only reliable path is to size everything, image width, command structure, and transmission pacing, to the physical limits of the hardware in the room.

The shipped printing package encodes that hard-won behavior so every merchant benefits from a debugging saga they never have to repeat.

Payments, subscriptions, and honest boundaries

Two money flows run through Algonize, and it helps to keep them separate.

The first is the customer paying for goods at checkout. Algonize records the payment method on every sale and order, and supports eight of them: cash, card, mobile banking (bKash, Nagad, Rocket, Upay), bank transfer, cheque, an online option, and cash on delivery for orders a rider carries. A sale can also hold an advance, so partial payments and dues are first-class, not a workaround.

The second is the merchant paying for the platform. Access is gated by a subscription. Plans define a full matrix of limits: how many branches, staff, vendors, inventory items, and riders a business may have, and how many sales and orders it may record per month. The dashboard measures real usage against those limits so a merchant always knows where they stand, and a fifteen-day free trial lets a business start before it pays.

The subscription payment flow is split cleanly between client and server, and it is worth stating exactly where the responsibility sits. The gateway interaction is orchestrated on the client side. The backend's role is to record the billing outcome and defend its integrity. Each payment stores its full breakdown, including subscription amount, promo discount, VAT, an Advance Income Tax field for the local tax regime, gateway charges, and the raw gateway response. Every payment record carries a signature that the backend checks on any update and rejects if it does not match, which detects tampering with a stored record. A zero-cost plan change activates immediately without a redirect. Payment availability itself is gated globally through remote configuration, so the platform can pause the flow centrally when needed. This is deliberately a record-and-verify design, not a claim of server-side gateway settlement, and describing it that way is the point.

Loyalty, promotions, and a fast counter

On top of the core, Algonize adds the engagement features a real business runs on. Loyalty points earn and redeem against configurable tiers, with a per-customer balance tracked against each business. Promo codes support percentage and fixed-amount discounts, scoped to subscriptions, sales, or orders, with usage limits, per-customer limits, and first-time-customer rules enforced by database constraints so an invalid combination cannot be saved. At checkout, both are validated against the backend before they touch the total.

For the counter itself, the Portal includes a standalone multi-tab quick-sale POS that mirrors the full sale form per tab, keeps each tab's cart cached as the cashier switches between them, and adds items with a tap, prompting for a variation when one exists. It is built as a self-contained module so the fast lane can evolve without disturbing the full sales workflow.

Built for real businesses, not one template

Algonize was shaped around how different shops actually work, so the same core serves several kinds of business without forcing any of them into the wrong mold.

Built to be found: SEO, AEO, and GEO

Discoverability was treated as part of the platform, not an afterthought. The backend exposes a set of unauthenticated public endpoints for storefront reads, so a business, its branches, its categories, its featured and categorized inventory, its ratings, and its plans can be rendered as fast, crawlable, server-side pages. That gives each merchant a public presence that search engines and AI answer engines can index and cite, rather than content locked behind a login. This case study itself follows the same principle: an answer-first summary, a clear question-and-answer structure, and structured data, so it can be surfaced directly by traditional search (SEO), by answer engines that quote a short response (AEO), and by generative engines that need clear, factual, quotable claims (GEO). It is one example of how Algoramming builds software to be discovered, not just built.

Results

• One platform, one truth. A merchant runs the whole business on the web, on desktop, or on a phone, replacing a stack of disconnected tools with one login and one source of truth.
• The order is followed to the door. Three apps, the Portal, the customer app, and the rider app, share one status pipeline, so an order's progress from checkout to doorstep is one connected story instead of three separate ones.
• Web-native thermal printing. A browser reaches a local network printer through a companion bridge, which is unusual to offer at all and rare to offer reliably across Windows, macOS, and Linux.
• A backend that enforces the rules that matter. The database itself guarantees stock cannot oversell and the ledger balances, regardless of which client made the request.
• Real-time notifications with a safety net. At-least-once delivery, exactly-once in practice, and no separate queue service to operate.
• Reusable, open building blocks. A published Flutter printing package and an open browser bridge turn a hard, hardware-specific problem into a dependency other teams can adopt.

Tech stack

---

Frequently asked questions

What is Algonize?

Algonize is an all-in-one business management and point-of-sale platform for small and mid-sized businesses. From one system, a merchant can manage sales, online orders, inventory, vendors, customers, staff, delivery riders, loyalty points, promo codes, analytics, and their subscription, across the web, desktop, and mobile. You can see the live storefront at customer.algonize.xyz.

Which devices and platforms does Algonize run on?

The same account runs on the web and as a native app on macOS, Windows, Linux, Android, and iOS, all from one Flutter codebase, so a merchant can start a sale on a desktop and finish the day on a phone with everything already in sync. It supports English and Bangla and works in BDT or USD.

Is there a dedicated app for delivery riders?

Yes. Algonize includes a separate rider app built on the same backend. A rider sees a live queue of the deliveries assigned to them, taps once to navigate to the customer using the order's saved location, sees the exact cash to collect on cash-on-delivery orders, and advances each delivery through the shared status pipeline. The rider also gets an earnings dashboard with total deliveries, completed deliveries, and delivery earnings over a chosen date range.

What payment methods does Algonize accept?

At checkout, Algonize records eight payment methods: cash, card, mobile banking (including bKash, Nagad, Rocket, and Upay), bank transfer, cheque, an online option, and cash on delivery. Sales can also hold an advance, so partial payments and dues are handled directly rather than worked around.

How can a web-based POS print to a thermal receipt printer?

Web browsers cannot open raw network sockets, which is what thermal printers require. Algonize solves this with a companion Chrome extension called Local TCP. The web app sends the receipt bytes to the extension, which relays them to a small Node.js helper installed on the computer, and that helper opens the actual network connection to the printer and prints. To the merchant it feels like the browser printed directly.

Why did cheap thermal printers print garbage, and how was it fixed?

Inexpensive thermal printers have small print buffers and strict image-mode rules that their advertised network settings hide. The receipt image had to be sized to the exact print-head width, sent as a single image command rather than per-line, generated on the correct thread, and streamed in paced chunks matched to the printer's real buffer. Getting all of those right together produced clean receipts. The fixes live in the flutter_esc_pos_network_universal package.

How does Algonize keep one business's data separate from another's?

It uses a multi-tenant model where every record is scoped to a business and usually a branch. A merchant reaches a business through a membership record called a contributor, and queries are always scoped to the tenant. Each business even gets its own invoice-number sequence, so counters never collide between tenants.

How does Algonize prevent overselling stock?

Stock validation runs inside PostgreSQL as a trigger before any sale or order is saved. It locks the affected items in a deadlock-safe order, checks requested quantities against live usage, and rejects any line that would go negative, regardless of which app or device made the request.

Does Algonize handle multiple branches with different tax and charge rules?

Yes. A branch is a first-class location under a business, and each branch carries its own defaults for VAT, service charge, delivery charge, and employee charge. Owners see every branch live from one dashboard, while each branch keeps its own financial rules.

What technologies is Algonize built with?

The apps are built in Flutter for web, desktop, and mobile. The backend is Node.js and TypeScript on Express with a PostgreSQL database that carries much of the business logic in triggers and functions. It uses Firebase Cloud Messaging for push notifications, Supabase for the database and object storage, and a custom Flutter package plus a Chrome extension for thermal printing.

Does Algonize support online ordering and delivery?

Yes. A customer app lets shoppers discover businesses, browse catalogs, place orders, pay, and redeem loyalty and promo codes. Merchants assign riders in the Portal, the rider carries the order in the rider app, and the customer can track which rider is handling their order in real time.

Can Algoramming build a platform like this for my business?

Yes. Algoramming designs and builds cross-platform products end to end. See more of our work or get in touch to talk about your project.

Key takeaways

• Solve the whole workflow, not one screen. The value of Algonize is that a sale, its stock impact, its ledger entry, its receipt, its delivery, and its loyalty points are one connected flow from storefront to doorstep rather than six disconnected tools.
• Follow the order to the door. A dedicated rider app on the same backend turns delivery from a phone-call scramble into a tracked, status-driven step that every screen can see.
• Let the database enforce what must never break. Putting stock validation and the double-entry ledger inside PostgreSQL means the rules hold no matter which client calls them.
• The web platform's limits are real, so bridge them deliberately. Printing from a browser to a local printer required a companion extension and a native helper, and getting that right made a headline feature possible.
• Hardware tells the truth that specs hide. Reliable thermal printing came from sizing image width, command structure, and transmission pacing to the printer's physical buffer, not its advertised capabilities.
• Design for discovery from the schema up. Public storefront endpoints and an answer-first content structure make both the product and its story easy for search and AI answer engines to surface.

---

Want one real-time command center for your multi-branch business, or a cross-platform product built to the same standard? Get in touch with Algoramming Systems Ltd. or explore more of our services.