Ordmero

Project Overview

Most small food and retail businesses run on a basic point-of-sale system for taking payments, plus a spreadsheet on the side for everything the POS doesn't handle — inventory counts, cost tracking, reporting. The two never talk to each other, so someone has to reconcile them by hand. I designed and built Ordmero, a multi-tenant business operating system that replaces that combination with one connected platform: every sale automatically updates inventory, cost, tax, and reporting in real time. It's now live with its first real client, a coffee shop in Punjab, Pakistan.

At a Glance

• ▹
  Business goal: Replace the basic-POS-plus-spreadsheet setup most small food and retail businesses run on with one connected system for sales, inventory, staff, tax, and reporting
• ▹
  Primary users: Owners, managers, and staff at small and mid-sized food and retail businesses — cafés, restaurants, bakeries, shops
• ▹
  Core solution: A multi-tenant SaaS platform where every sale automatically drives inventory deduction, cost and margin calculation, tax, and financial reporting
• ▹
  Key outcome: Live in production with its first paying client, on an architecture built from day one to serve many businesses on one codebase

Client or Business Context

Ordmero targets small and mid-sized food and retail businesses — the kind that need more than a checkout screen but aren't the market for enterprise restaurant software. Its first live client, a coffee shop in Punjab, Pakistan, had been running on a basic POS for taking sales, with a separate spreadsheet on the side to track inventory and costs — a common setup at this scale, and one where the two systems never actually connect.

Ordmero is priced as a one-time setup fee per client, followed by a three-month free usage period, then an ongoing monthly subscription. Onboarding is delivered white-glove rather than self-serve — I configure each client's menu, recipes, tax rules, and staff accounts myself before their team ever logs in, rather than expecting a café owner to configure a business operating system on their own.

Project Positioning

Ordmero is an independent product initiative — built and owned entirely by me, operating under the Sharpkode/SynqShip umbrella, and delivered as a multi-tenant SaaS product rather than custom work for a single client. The coffee shop in Punjab is its first real, paying client, with the platform architected from the start to expand to more businesses and eventually more regions.

The Challenge or Opportunity

What Was Not Working

• ▹
  A basic POS handles taking payment and little else — inventory, cost, and reporting are left to a separate spreadsheet
• ▹
  Because the POS and the spreadsheet don't connect, stock levels and cost-of-making figures have to be updated by hand, and drift out of sync with what's actually being sold
• ▹
  Fixed staff roles (or none at all) don't reflect how small businesses actually assign responsibility, where one specific manager might need one extra permission without every manager getting it
• ▹
  Local tax rules that change over time (Punjab's PRA rates have changed multiple times) usually mean waiting on a software update, or adjusting numbers manually in the meantime
• ▹
  A basic POS generally assumes a stable internet connection, which isn't a safe assumption at a counter

Why It Mattered

When inventory and cost tracking live in a spreadsheet instead of the point-of-sale system itself, the numbers are only ever as current as the last manual update — so margin and stock figures are usually stale, and reconciling a shift's cash against the system total becomes a manual, error-prone exercise instead of something the system does on its own.

Project Goals

1. ▹
   Connect every sale automatically to inventory, cost, tax, and reporting, removing the manual reconciliation step between separate tools
2. ▹
   Make inventory recipe-driven, so cost-of-making and margin per item are calculated from real ingredient data instead of entered by hand
3. ▹
   Build staff permissions granular enough to reflect how a real small business actually assigns responsibility
4. ▹
   Keep the system usable through internet outages at the counter, without losing or duplicating sales
5. ▹
   Architect the platform as multi-tenant from day one, so one codebase can serve many differently-branded businesses

The Approach

1. Understanding the Problem

The clearest signal came from looking at what businesses like the pilot coffee shop were actually running: a basic POS for sales, plus a spreadsheet on the side for everything else. That gap — where the two systems don't talk to each other — became the core problem Ordmero needed to close, rather than just building a better checkout screen.

2. Defining the Right Scope

Key scope decisions:

• ▹
  Inventory had to be recipe-driven from the start, not a manually-updated count bolted on later, since a bolted-on inventory module would have reproduced the same disconnect the spreadsheet already had
• ▹
  Tax rates are stored per branch and per payment method with effective dates, rather than hardcoded, specifically because local rules like Punjab's PRA rates change without warning and a hardcoded rate would mean a software update every time they did
• ▹
  Onboarding stayed white-glove instead of self-serve: I personally configure each client's menu, recipes, tax rules, and staff accounts before their team logs in
• ▹
  Multi-currency, multi-language, payroll, and supplier tracking were deliberately left out of this version, so the core sales–inventory–tax–reporting loop could be built properly first

3. Designing the Solution

Core solution components:

• ▹
  Recipe-driven inventory: every menu item is linked to its exact ingredients and quantities, so every sale deducts real stock and calculates cost-of-making and margin automatically
• ▹
  Granular staff permissions: beyond the Owner/Manager/Cashier defaults, individual staff members can get custom permission overrides — for example, one specific manager granted menu-editing access that other managers don't have
• ▹
  Built-in financial reporting and shift reconciliation: daily, weekly, and monthly profit tracking and expense logging live in the same system as the sales that produced them, and end-of-shift reconciliation flags any discrepancy between the system total and actual counted cash
• ▹
  Offline-first, event-sourced reliability: sales, inventory deduction, and receipt printing keep working through an internet outage at the terminal, with every sale and stock change logged as an event and replayed on sync once connectivity returns, rather than just overwriting whatever state exists when the connection comes back

4. Building and Validating

Ordmero is a Progressive Web App built with React and Vite, installable and offline-capable through local IndexedDB storage, on a Supabase (Postgres) backend hosted on Vercel. Row-level security is enforced per business, so client data stays fully isolated tenant to tenant on the same shared codebase. The marketing site and the product app live in one monorepo — a Next.js marketing site and a Vite PWA product app — sharing a common design-tokens package, deployed to a root domain and a product subdomain respectively. The platform is now live with its first real client.

5. Solving the Hardest Problem

Challenge: Making offline resilience actually trustworthy, not just a workaround

Why it was difficult: A till at the counter can't afford to lose a sale, double-count a sale, or silently drift out of sync with inventory just because the internet drops mid-shift. A simple "save state and overwrite on reconnect" approach carries real risk here, since two devices reconnecting out of order can clobber each other's changes.

Decision made: I built Ordmero as an event-sourced system — every sale and every stock change is recorded as an append-only event locally, then synced and replayed on the backend, rather than overwriting a single stored state.

Outcome: Sales, inventory deduction, and receipt printing continue uninterrupted through an outage at the terminal, and once connectivity returns, events replay in order instead of risking a conflict between what happened locally and what the backend already had.

The Solution

Ordmero gives a small food or retail business one system to run its counter, instead of a POS plus a side spreadsheet. A sale isn't just a transaction — it automatically deducts the right ingredients from inventory, calculates the cost and margin for that item, applies the correct tax for the branch and payment method, and feeds straight into the day's financial reporting. Staff log in individually with a PIN, discounts and voids require manager approval and are logged to an audit trail, and at the end of a shift the system reconciles its own total against the cash actually counted.

Key Capabilities

• ▹
  Recipe-driven inventory: automatic, real-time stock deduction and cost/margin calculation tied to each menu item's exact recipe, not a manually maintained count
• ▹
  Granular staff permissions: role defaults (Business Admin, Manager, Cashier) plus individual permission overrides for specific staff members
• ▹
  Built-in financial reporting and shift reconciliation: profit tracking, expense logging, and end-of-shift cash reconciliation with discrepancies flagged automatically
• ▹
  Configurable, per-branch tax handling: tax rates stored per branch and payment method with effective dates, so local tax changes don't require a software update
• ▹
  Offline-first reliability: sales, stock deduction, and receipt printing keep working through an outage, with event-sourced sync that replays safely once connectivity returns
• ▹
  Payments: cash and card support with tax calculated correctly per method — card payments run through the business's own card machine, with Ordmero recording the transaction and applying tax rather than processing the payment itself
• ▹
  Multi-tenant branding: one codebase serves many clients, each with isolated data and their own receipt branding, without forking the code. The in-product identity itself leans into the industry it serves — a warm cinnamon-and-cream palette and a "receipt-tape" motif of dotted dividers and monospace tabular numerals, echoing a physical thermal receipt

Key Results

Ordmero is live with its first real client, a coffee shop in Punjab, Pakistan. Because the client only recently went live, there's no formal usage data yet — the results below reflect what's been built and delivered rather than measured outcomes.

Product and User Outcomes

• ▹
  Delivered a single connected system in place of the pilot client's previous basic POS and side spreadsheet, so inventory, cost, and reporting update automatically from each sale instead of requiring manual reconciliation
• ▹
  Replaced manual cost-of-making and margin calculation with automatic, recipe-based figures tied to real stock movement
• ▹
  Gave the client's staff individual, PIN-based logins with role and permission-level control, instead of shared access or fixed roles
• ▹
  Built shift-end cash reconciliation directly into the same system the sales run through, rather than as a separate manual step

Technical Outcomes

• ▹
  Architecture: a Progressive Web App (React/Vite) with offline capability via IndexedDB, backed by Supabase/Postgres on Vercel
• ▹
  Data integrity: event-sourced sync design — append-only events replayed on reconnect — rather than overwrite-on-sync, built specifically to avoid data conflicts after an offline period
• ▹
  Multi-tenancy: row-level security enforced per business, so the same codebase serves multiple clients with fully isolated data
• ▹
  Configurability: tax rates configurable per branch and per payment method with effective dates, so regulatory changes don't require a software release

Qualitative Results

• ▹
  Live in production with a real, paying client
• ▹
  Built as a genuine multi-tenant platform from day one, not adapted from a single-client build after the fact
• ▹
  Designed specifically to remove the manual reconciliation step between a POS and a spreadsheet that businesses like the pilot client were relying on before

Impact

For a business used to running sales through a basic POS and tracking everything else in a spreadsheet, having inventory, cost, tax, and reporting update automatically from every sale removes a manual reconciliation step that previously depended on someone remembering to do it — and getting it right. Recipe-driven cost and margin figures reflect what was actually sold and used, not a spreadsheet estimate that's only as current as the last manual update. And because the system keeps working through an internet outage at the counter, a dropped connection during a shift no longer means lost sales, an untrustworthy total, or a scramble to reconstruct what happened once it reconnects.

Because Ordmero was built multi-tenant from the outset, rather than adapted from a single-client build, bringing on the next business means configuring their menu, recipes, tax rules, and staff accounts on the same platform — not rebuilding the system around a second client.

Technologies and Skills Demonstrated

Technology Stack

• ▹
  Frontend: React, Vite, Progressive Web App (installable, offline-capable via IndexedDB)
• ▹
  Backend: Supabase (Postgres), hosted on Vercel
• ▹
  Data architecture: Event-sourced sync (append-only local events, replayed on reconnect), row-level security for per-tenant data isolation
• ▹
  Marketing site: Next.js, SEO-optimized, sharing a design-tokens package with the product app in a single monorepo

Skills Demonstrated

• ▹
  Multi-tenant SaaS architecture and data isolation
• ▹
  Offline-first application design with conflict-safe sync
• ▹
  Domain modeling for a real operating business — recipes, inventory, tax, staff permissions, shift reconciliation
• ▹
  End-to-end product ownership: architecture, build, business model, and client onboarding
• ▹
  Configurable, regulation-aware system design, built around per-branch and per-payment-method tax handling

My Role and Contribution

I designed, built, and own Ordmero entirely on my own, operating under the Sharpkode/SynqShip umbrella.

I was responsible for:

• ▹
  Product concept, scope, and business model, including the white-glove onboarding approach and subscription structure
• ▹
  The full technical architecture: the PWA frontend, Supabase/Postgres backend, event-sourced offline sync, and row-level multi-tenant security
• ▹
  Every core module: selling, recipe-driven inventory, staff and permissions, reporting and reconciliation, and per-branch tax configuration
• ▹
  Onboarding the first live client, including configuring their menu, recipes, tax rules, and staff accounts before handover
• ▹
  Brand identity and the in-product design system, including the "receipt-tape" visual motif used throughout

Team setup: Solo founder and developer.

Lessons and Reflection

• ▹
  What worked well: Treating offline reliability as a core architectural decision — event-sourced sync — instead of an add-on feature meant it didn't need to be retrofitted once a real terminal started dropping connections at the counter.
• ▹
  What I would improve: I don't have formal usage or feedback data from the first client yet. I'd put a simple mechanism in place for tracking basic engagement and gathering feedback from the first week, rather than only after growing to more clients.
• ▹
  What the project taught me: Building for one real client while architecting for many at the same time meant every decision — from tax configuration to onboarding — had to hold up beyond that first coffee shop, not just solve its immediate case.

Closing Summary

Ordmero replaces the basic-POS-plus-spreadsheet setup many small food and retail businesses run on with one connected system: every sale automatically drives inventory, cost, tax, and reporting, and the platform keeps working through an internet outage at the counter. Built and owned solely by me as a multi-tenant SaaS product, it's now live with its first real client, a coffee shop in Punjab, Pakistan, on an architecture designed from day one to support many more.

Project takeaway: Built and shipped a genuine multi-tenant business operating system solo, replacing a real client's disconnected POS-and-spreadsheet setup with one automatically reconciling system.