Tillo
Tillo is an offline-capable point of sale and store-operations SaaS for small physical merchants.
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.
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.
- Checkout, barcode/PLU search, mixed tenders, provisional/canonical receipts, browser printing/PDF and reprint history.
- Browser-only offline durability, device registration, persistence request, queue warnings/hard stop, recovery export and manager conflict inbox.
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.
- Merchant catalog, one base price list, stock movements/on-hand, one location, cash shifts and variance.
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.
- 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)
- Manager/Cashier fixed templates, staff-to-location assignment, audit evidence, non-fiscal receipt disclosure and one seeded country profile.
Tenders. A sale can be paid with cash, a bank transfer reference, an external card reference, or a mix of several tenders on one sale. An integrated card terminal is used only where the merchant has configured one; without it, card payments are recorded as external references so the sale still balances.
Refunds and voids. Full and partial refunds and voids of completed sales are available on every plan. A refund is a new, audited movement — it reverses money, stock and any customer balance, and the original sale is never rewritten. A reason is mandatory, and who may approve one is a permission setting rather than a plan boundary.
Cash shifts. A register's day runs inside a shift: an opening float, cash-in and cash-out movements during the day, and one close. The close can be a blind count (the counted cash is entered before the expected figure is shown), and it records expected, counted and variance. A shift closes exactly once — a second attempt from another tab or a retried request cannot close it twice or post a second variance.
Receipts. Every completed sale gets a canonical receipt number issued by the server. When a sale is rung offline, a provisional local number is shown and is mapped to the canonical one at sync, so the paper the customer took home can still be traced. Receipts reprint exactly as issued.
An honest metric or none. Where a figure cannot be measured — a count that failed, a field the sale record does not carry — the screen says it was not measured instead of showing a zero. On a reconciliation page a confident wrong number is worse than a blank, because it reads as evidence against a named cashier.
What works offline. Cash and named manual tenders, cart building, catalog lookup against the data already on the device, and printing. Integrated card payments do not — those always need the provider, and the product does not pretend otherwise.
The ceiling is deliberate and visible. Offline is bounded: a device may hold up to 500 queued operations or run up to 24 hours without syncing, whichever comes first. Warnings escalate as the queue fills — at 50%, 75% and 90% — and at the ceiling the device stops accepting new offline sales. Sync, inspection, and the recovery export stay open at the ceiling: it is a safety limit, not a lockout. These limits are the same on every plan and cannot be purchased away, because they exist to protect the merchant's data rather than to sell an upgrade.
Recovery export. At any point a device can export its queued operations to a file. That is the escape hatch if a device has to be wiped or replaced before it can sync.
Sync and conflicts. Queued operations are sent with a stable operation id, a device sequence number and a payload hash. If a response was lost and the same operation is retried, the server returns the original sale and receipt rather than creating a second one. The same id arriving with a different payload is a conflict, not a duplicate, and it is held for a human.
needs_review. When two devices sell the last unit of something while one of them was offline, the physical sale is not thrown away and stock is not silently driven negative. The operation is marked needs review and appears in the manager's conflict inbox, where a person decides what actually happened. Nothing is auto-corrected behind the merchant's back.
Stock is a ledger, not a number. On-hand quantity is derived from movements, never edited directly. A sale decrements, a refund reverses, a receipt of goods increments, and a manual adjustment requires a reason. That is what makes stock auditable months later: every unit that moved has a row saying why.
Counts and transfers (available above the entry plan) let a merchant count a location's stock against the ledger and move stock between locations, each posting its own movements rather than overwriting a figure.
Purchasing (available above the entry plan) covers suppliers, purchase orders, and receiving. Receiving all or part of an order posts the stock movements and the cost update together, and it is retry-safe — receiving the same delivery twice because a request timed out does not double the stock.
Promotions (available above the entry plan) are rules on products, categories, quantities or combinations, applied in a fixed priority order so the same cart always produces the same discount. A rule can be previewed before it goes live, and checkout recomputes the discount on the server regardless of what the browser calculated.
Labels and tickets. Receipt printing is always browser-based. Label printing is available above the entry plan. A local raw-printer bridge is optional — the product works without one.
Low stock. Items at or below their reorder point are surfaced in the operations digest along with unresolved sync conflicts and shifts left open beyond policy. The digest reports; it never resolves anything on its own.
Beyond the platform-side roles, a merchant organization has three:
The platform underneath the product — counted in this product's own source, not claimed from a template. Where a row carries a list, open it to read the names behind the number.
Coinbase
dLocal
Flutterwave
Komoju
Mollie
NOWPayments
Opn
Paystack
ActiveCampaign
Customer.io
Segment
Canny
Amplitude
Custom Head Scripts
Pushover
Twilio SMS
Crisp
Tawk.to
Monday.com
fal.ai
Axiom
hCaptcha
Freshsales
Pipedrive
Pabbly Connect
AWS S3
MuxHover a table to isolate what it touches; click one to read its relationships. The big nodes are what everything else hangs off. organizations is referenced by 73 tables because every single record in this product belongs to an organization, and that is what makes tenant isolation a property of the database rather than something the application has to remember on every query.
all 86 tables, as text
active_boosts · admin_notifications · analytics_daily · analytics_events · analytics_funnels · announcement_dismissals · announcements · api_key_logs · api_keys · assistant_actions · assistant_conversations · assistant_messages · assistant_usage · audit_logs · automation_log · automation_templates · cash_movements · cash_shifts · catalog_items · catalog_variants · country_profiles · credit_balances · credit_transactions · currencies · customer_account_movements · customers · data_exports · data_imports · faq_categories · faq_items · feature_flags · goods_receipts · inbound_webhook_events · inbound_webhooks · inventory_counts · inventory_transfers · item_barcodes · languages · locations · marketing_audience_members · marketing_audiences · merchant_categories · merchant_staff_assignments · notification_log · notification_rules · notifications · organization_limit_overrides · organizations · plans · platform_secrets · platform_settings · price_list_items · price_lists · product_purchases · products · promotion_rules · provider_prices · purchase_order_lines · purchase_orders · push_devices · receipt_mappings · refund_lines · refunds · registered_devices · registers · report_templates · roles · sale_lines · sales · scheduled_tasks · seo_meta · stock_balances · stock_movements · subscriptions · suppliers · sync_conflicts · sync_operations · tenders · theme_page_sections · theme_section_library · theme_sections · translations · user_sessions · users · webhook_logs · webhooks
The chassis, and anything particular to this product. 3 required, 2 optional.
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.
The Supabase client is present in the product dependencies.
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.
Provider adapters ship for Brevo, Mailgun, Resend, SendGrid and SMTP. Configure one only when the deployment sends email.
The measured example configuration groups UPSTASH, NEXT and SENTRY keys. NEXT keys are host/public configuration rather than a separate service.
Already built — plug and play
Every provider integration in this list ships wired into the product. You bring your own keys, connect them in the admin, and go live — there is no integration code to write. Nothing is resold through us: the ongoing cost is whatever these providers charge you. Capabilities marked plan-gated elsewhere on this page unlock by plan, not by extra code.
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.