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

TL;DR (answer-first summary): Algoramming built Algonize, an all-in-one business management and point-of-sale (POS) platform that turns a scattered set of tools into a single real-time command center. A multi-branch business can run its storefront, checkout, inventory, staff, delivery riders, loyalty, and subscription billing from one system, on the web, on desktop, or on a phone, while every branch and every device stays in sync through one backend. The ecosystem is one Node.js and PostgreSQL backend serving a Flutter merchant Portal, a Flutter customer ordering app, a purpose-built ESC/POS thermal printing package, and a companion Chrome extension that lets the web version print receipts to a local network printer, something browsers cannot normally do. This case study explains the three hardest problems we solved: multi-tenant data isolation, web-native thermal printing, and following a single order all the way from storefront to doorstep in real time. If you want a platform like this, talk to Algoramming.

---

The problem

Small and mid-sized businesses do not fail for lack of effort. They fail because their tools do not talk to each other. A shop owner ends up with 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 the day was profitable. Every one of those tools assumes a different device, a different login, and a different definition of a "sale." When the business grows to a second or third branch, the gaps turn into daily firefighting.

Algoramming set out to replace that pile of disconnected tools with one command center. The product, Algonize, needed to do several things that are individually common but rarely solved together well:

• Run the same business on any device the merchant already owns, including a plain web browser, a Windows or macOS desktop, and an Android or iOS phone, without asking them to buy special hardware.
• Handle a real point of sale, meaning fast checkout, product variations, stock that decrements correctly, 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 tenant's data.
• Extend past the counter into online orders, delivery with assigned riders, customer loyalty points, promo codes, and a subscription that gates how much of the platform a merchant can use.
• Keep every branch, every device, and every actor 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 web browser is not allowed to open a raw network socket. That one sentence produced weeks of the most interesting engineering in the project.

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.

A useful way to read the rest of this study: the backend defines the truth, the Portal and customer app consume it, and the printer 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 of it move in real time from one dashboard. Because all of that 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, several honest clients

The Portal and the customer app are both Flutter applications and deliberately share the same conventions, so a developer who knows one can read the other. Both use 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 two 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, expanded relationships and all. The Portal is the full operating system with roughly twenty-six modules. The customer app is a trimmed consumer client that carries many of the same models purely so it can read what the backend sends back. This shared-convention discipline is the same approach Algoramming applies across its work, from mobile apps to the AI-native content platform we describe in a companion case study.

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 the whole starting world for them: 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 have 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, distinguishing any authenticated user from a merchant and from a super admin. 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 and customers need timely push notifications: a new order, a status change, 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.

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. 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 is that 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.

Subscriptions, billing, and honest boundaries

Access to the platform 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.

The 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 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

• A single platform that a merchant can run on the web, on desktop, or on a phone, replacing a stack of disconnected tools with one login and one source of truth.
• Web-native thermal receipt printing, a browser reaching 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 multi-tenant backend where the database enforces the rules that matter most, so stock cannot oversell and the ledger balances itself regardless of which client made the request.
• Real-time notifications with an at-least-once safety net and no separate queue service to operate.
• A reusable Flutter printing package and an open browser bridge that turn a hard, hardware-specific problem into a dependency other teams can adopt.

Tech stack

Clients: Flutter targeting web, macOS, Windows, Linux, Android, and iOS, using Riverpod for state, go_router for routing, get_it for dependency injection, and Hive for local storage. Backend: Node.js with TypeScript on Express, organized as a modular monolith with no ORM, using PostgreSQL with substantial logic in triggers, functions, and views. Data and infrastructure: PostgreSQL on Supabase, object storage through the S3-compatible Supabase Storage API, JSON web tokens for authentication with access and refresh tokens, PM2 for process management, and rate limiting, request logging, and centralized error handling as first-class middleware. Notifications and messaging: Firebase Cloud Messaging through Firebase Admin, transactional email, and SMS through a regional provider. Printing: a custom flutter_esc_pos_network_universal package for ESC/POS network printing on every platform, and a Manifest V3 Chrome extension with a Node.js native messaging host that bridges the browser to a local TCP printer.

---

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.

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.

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 separate customer app lets shoppers discover businesses, browse catalogs, place orders, and redeem loyalty and promo codes. Merchants manage riders in the Portal and assign them to deliveries, and the customer can see which rider is handling their order.

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, and its loyalty points are one connected flow from storefront to doorstep rather than five disconnected tools.
• 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.