# Tillo

> Tillo is an offline-capable point of sale and store-operations SaaS for small physical merchants.

Source page: https://saascode.ai/products/tillo
Machine-readable record: https://saascode.ai/products/tillo.md

One-time purchase · full source code · self-hosted by the buyer.

Price: $149 (one-time)

## How to read this document

Written for a model auditing this product on a buyer's behalf. Two labels
appear throughout and they mean different things:

- **measured** — produced by a script reading the product's own source tree
  or database at the stated date. The method is named beside each number.
- **stated** — written by the seller. True or not, it is a claim, and this
  document does not ask you to treat it as evidence.

The live demo is the strongest verification available from outside: it runs
the same source a buyer receives. Nothing to sign up for — the public side is
open, and the seeded credentials below get you into each role.

## What it is

This is a point-of-sale and store-operations product for small physical merchants. A merchant signs in, opens a cash shift on a register, scans or searches items, takes payment, and prints a receipt from the browser. Around that register it also keeps the catalog, stock, cash, customers, suppliers, purchases, promotions and reports that a small shop actually runs on.

## Live demo

Two doors into the same running instance, and the same source a buyer
receives. There is no account to create; the public side is open, and the
seeded credentials below sign you into each role.

- **Guided (recommended):** https://saascode.ai/demo/tillo — our shell, with a role switcher and
  the credentials in the menu. Best for a person.
- **Direct:** https://tillo.saascode.ai — the product on its own, no chrome.
  Best when you are relaying steps to someone, or fetching a page.

4 roles seeded on the demo (of the 6 the schema defines — the build data below counts them all). Credentials are published deliberately: these
are demo accounts on a public demo instance, and a reviewer who cannot get
in cannot verify anything.

- **Cashier** (`cashier`) — `cashier@demo.com` / `demo123`
  Rings sales, manages a shift and reprints receipts. Lands on `/app/checkout`.
- **Merchant owner** (`org_admin`) — `org-admin@demo.com` / `demo123`
  Runs locations, staff, billing and store settings. Lands on `/app/today`.
- **Store manager** (`manager`) — `manager@demo.com` / `demo123`
  Approves corrections and runs stock, purchasing and reports. Lands on `/app/today`.
- **Platform owner** (`super_admin`) — `admin@demo.com` / `demo123`
  Runs merchants, plans, integrations and platform controls. Lands on `/admin/pos`.

Or open a role directly: https://saascode.ai/demo/tillo?role={role}

## Measured build

*measured — each number names the method that produced it.*

- **roles: 6** — distinct roles accepted by the role CHECK constraint: admin, cashier, manager, member, org_admin, super_admin
- **tables: 86** — distinct CREATE TABLE statements across every applied migration
- **migrations: 114** — .sql files in supabase/migrations
- **page modules: 130** — files named page.tsx under src/app, excluding node_modules and .next
- **source lines: 183,736** — lines of code (comments and blank lines excluded) across 1192 TypeScript files (161,296) and 140 SQL files (22,440); node_modules and .next excluded
- **api route files: 267** — files named route.ts under src/app/api
- **http operations: 355** — exported HTTP method handlers across those files, de-duplicated per file, OPTIONS excluded as CORS preflight
- **schema graph: 86 tables, 169 relationships** — parsed from the applied migrations

A large number here is scope, not quality. It says the product models a
real domain rather than a CRUD skeleton; it says nothing about code
quality, duplication, test coverage or maintainability, and should not be
read as if it did.

Release: v1.0.0 · built 2026-08-20

## Complete capability inventory

5 capabilities. Each summary is *stated* — selected from the
product's own buyer documentation, or written by the seller where marked.

### Selling, refunds and cash shifts

- **Checkout, barcode/PLU search, mixed tenders, provisional/canonical receipts, browser printing/PDF and reprint history.** — Checkout. A sale is built from a cart: items are added by barcode scan or search, quantities and discounts are set per line, and the total is recomputed on the server at the moment of payment. A cashier can remove or void a mistaken line before payment on every plan — a correction is never something a merchant has to buy.
- **Sales history, full/partial refunds, completed-sale voids, customer directory, basic reports and CSV import/export within plan row limits. (Sales history, full and partial refunds, completed-sale voids, customer directory, basic reports, and CSV report export within plan row limits)** *(seller-authored)* — Sales history, full and partial refunds, completed-sale voids, customer directory, basic reports, and CSV report export within plan row limits

### Working offline, devices and sync

- **Browser-only offline durability, device registration, persistence request, queue warnings/hard stop, recovery export and manager conflict inbox.** — Setting up a device. Each till is registered once, online, against a location and a register. Registration is what gives the browser its local operation log and lets it work through an outage afterwards. The product asks the browser for persistent storage at that point, so the queue is not evicted when the device is short of space.

### Catalog, stock, purchasing and promotions

- **Merchant catalog, one base price list, stock movements/on-hand, one location, cash shifts and variance.** — Catalog. A merchant's catalog holds items, their variants, barcodes, categories, prices and costs. Price lists let a merchant keep more than one set of prices; every item resolves through a base price list by default. This is the merchant's own catalog and it is entirely separate from the subscription plans the merchant buys.

### Roles, plans, locations and what each tier includes

- **Manager/Cashier fixed templates, staff-to-location assignment, audit evidence, non-fiscal receipt disclosure and one seeded country profile.** — Manager and Cashier ship as fixed permission templates in this release. The permissions are stored as capabilities underneath, so a future editor will not need the data to be migrated, but a merchant cannot edit the templates today.

## What each system gives the operator

*stated.*

- **Checkout and cash control** — Keep checkout and cash shifts accountable without splitting the store's operating record.
- **Offline continuity** — Keep the counter operating through outages without losing the day's trail.
- **Stock and purchasing** — Connect catalog, stock and purchasing to the work happening in the store.
- **Store operating roles** — Give every store seat a clear operating boundary as the business grows.

## The problems it was built to solve

*stated — the seller's argument, given in full so you can judge it.*

### The counter keeps moving when the connection does not.

A small shop cannot pause its busiest hour because the connection blinks. When the counter stops, a line forms, staff improvise on paper, and the day's sales record splits between memory, notes and the system. Even after service returns, nobody is certain which transaction was completed, which customer was charged, or which stock movement belongs in the books. The cost is larger than one delayed payment: trust at the counter falls, reconciliation takes longer, and every later report starts from a record the team has to question.

### Stock and purchasing stay connected to the work happening at the counter.

Inventory becomes unreliable when sales, receiving, supplier orders and corrections live in separate places. Staff stop believing the on-hand figure, managers over-order to protect themselves, and the next count becomes a project instead of a check. A single missing movement then spreads: purchasing looks late, margins become harder to read, and the counter promises an item the shelf cannot supply. Small merchants feel that cost immediately because the same people selling are also receiving deliveries and answering customers. They need one operating story they can follow without rebuilding it from spreadsheets every evening.

### Every location stays legible as sales, staff and customers accumulate.

Adding a location multiplies the places where ordinary uncertainty can hide. A refund cannot be explained, a shift closes with a variance, or a report shows a total nobody can trace back to the counter that produced it. If each store keeps its own informal process, the owner learns about the problem only after the numbers are consolidated by hand. That slows decisions and turns routine support into an investigation across messages and spreadsheets. Growth should widen the business, not widen the gap between what happened in each store and what the people responsible can understand.

## What it takes to run it

*stated — external services the buyer supplies and pays for directly.*

- **Node.js host with Next.js 16.2.10 and React 19.2.3** (required) — The application requires a Node.js host. The product package does not pin a Node.js runtime version, so select one supported by this Next.js release.
- **Supabase** (required) — The Supabase client is present in the product dependencies.
- **Scheduled-job runner** (required) — Wire the three schedules declared in `vercel.json`: scheduled tasks every minute, analytics maintenance daily at 02:15, and audience sync every six hours at minute 45. On Vercel these are cron entries; another host needs equivalent scheduling.
- **Email delivery adapter** (optional) — Provider adapters ship for Brevo, Mailgun, Resend, SendGrid and SMTP. Configure one only when the deployment sends email.
- **Optional environment integrations** (optional) — The measured example configuration groups UPSTASH, NEXT and SENTRY keys. NEXT keys are host/public configuration rather than a separate service.

## FAQ

**What exactly do I receive after purchase?**

The complete source repository behind the live demo — 183,736 lines across the application and its database, 86 tables defined by 114 migrations that the shipped scripts apply for you, plus the seed data, the demo accounts and the setup documentation. Not a subset and not a scaffold: the same code that runs the demo you just used.

**Is the live demo the same product whose source I receive?**

Yes. The Tillo demo runs the delivered release (v1.0.0), and the build figures on this page are measured from that same source — not from a showcase build kept separately.

**Can I test every account role before buying?**

Yes — all 4 of them: Cashier, Merchant owner, Store manager, Platform owner. Each one is seeded in the live demo and reachable from the role board above, so you can inspect the product from the customer's side, the agent's side and the administrator's side before you decide.

**Is this a complete product or a starter template?**

Complete. 130 page modules and 355 HTTP operations, with authentication, roles, billing, an administration panel, background jobs and seeded demo data all wired and running. A template gives you the shape of an application; this is one you can deploy and start operating.

**Can I rebrand and modify it?**

Yes, without asking. The name, identity, copy, styling and code are yours to change. Rebranding and operating it as your own service is exactly what the licence is for.

**What does the licence allow?**

A perpetual, worldwide, non-exclusive, non-transferable licence to the product you bought and to every update released for it. The Standard licence covers one business — yours. If you deploy for clients, the Client licence covers up to five. You can modify it, rebrand it, deploy it and charge your own customers.

**Can I resell the source code?**

No. Reselling, redistributing, sublicensing or giving away the source itself is not permitted under either licence. You build and deliver products with it — the code stays with you.

**What services and ongoing costs are required?**

You bring your own accounts, so we never mark anything up and there is no ongoing cost to us beyond the purchase. Required: Node.js host with Next.js 16.2.10 and React 19.2.3, Supabase, Scheduled-job runner. Optional: Email delivery adapter, Optional environment integrations. The table above says exactly what stops working without each one; most have usable free tiers at low volume.

**How difficult is deployment?**

Two ways, and most buyers use the first. The installer in your saascode dashboard walks it: you create free accounts at Vercel and Supabase, connect them, and it provisions the database, applies 114 migrations, seeds the data, deploys and verifies the result — you watch the steps go green. Or take the source and do it yourself with the shipped scripts and docs, which is the same sequence run by hand.

**What updates and support are included?**

Updates to that product for as long as we maintain it — no renewal fee and no expiry date on your access. Support covers download problems, defects in the code as shipped, questions about what the product does and how it is structured, and licence questions. It does not cover debugging your own modifications, building features for you, or setting up your hosting and third-party accounts.

**Why does a complete codebase cost $149?**

Because it was built once and is distributed many times. SaaSCode builds each product and ships the same finished release through the catalog, so the price reflects repeatable distribution — not a reduced codebase, an unfinished template, or what the same work would cost commissioned.

**Do I need to be a developer?**

No, for the normal path. You create free accounts at Vercel and Supabase, connect them to the installer in your saascode dashboard, and it does the deployment for you — provision, migrate, seed, deploy, verify. What it asks of you is creating two accounts and copying a token, not writing code. If you would rather deploy it yourself, or host it somewhere else, the full source and the scripts are yours to do that with. Running the product day to day needs no technical skill at all: that happens through its own interface, which is what the demo shows.

## Licence

The buyer receives the complete source and may deploy, modify and operate it
as their own SaaS, charging their own customers. The source itself is not
resold or redistributed: you build and deliver **with** it, you do not sell **it**.

## What this document cannot tell you

Stated plainly because a review that misses it is not a review:

- code quality, duplication, or architectural consistency
- test coverage
- query performance under load
- security posture beyond what the stack implies
- how maintainable it will be in a year

Scope is measurable from outside; implementation quality is not. Anyone
evaluating this should say so rather than infer quality from size.

## Written about it

- [Retail POS platforms ranked by who owns the next change (2026)](https://saascode.ai/inside/retail-pos-platforms-who-owns-the-next-change-2026.md)
- [Tillo: an offline-capable retail POS and store-operations SaaS](https://saascode.ai/inside/tillo-offline-capable-retail-pos-store-operations-saas.md)
- [Tillo vs Square POS and the white-label POS route](https://saascode.ai/inside/tillo-vs-square-pos-and-white-label-pos.md)

## Links

- Catalog page: https://saascode.ai/products/tillo
- Product record: https://saascode.ai/inside/products/tillo
- Live demo: https://tillo.saascode.ai
- Every product: https://saascode.ai/llms.txt