Reddy Till: The Cloud POS We Built for Multi-Shop Retailers

Project Description

Project Overview

Reddy Till is a cloud-based point-of-sale system for retail shops, and it is one of our own. Unlike most of the work in this portfolio, there is no client behind this project: we designed it, built it, documented it, and we operate it ourselves at reddytill.webwizard.ie. It sits alongside Poisa, Finafy, and TimeIn in our family of in-house web applications, and like those products it exists because we wanted to prove something specific: that a full retail POS, checkout, inventory, cash control, and staff management, can run entirely in a web browser on hardware the shop already owns.

The product's own positioning puts it plainly: "Run your shops from anywhere in the world." A retailer opens Chrome or Edge on any Windows or Mac machine, pairs the terminal, plugs in a standard USB receipt printer and cash drawer, and starts selling. The owner then checks live sales, stock levels, and who is clocked in from a phone while off-site. No proprietary till hardware, no per-feature pricing tiers, no software to install at the counter.

This case study is written the way we write all of them: only what you can verify on the live product and its public documentation appears below. Because we are the builder rather than an agency reporting a client's outcome, the useful detail here is the decisions: what we built into the product, and why each piece exists.

Project Summary

The Challenge

A point-of-sale system is unforgiving software. If a booking site goes down, someone emails instead. If a till stops working at 11am on a Saturday, the shop stops trading. Every design decision in Reddy Till had to answer to three people at once: the owner who counts the cash at night, the manager watching stock move, and the cashier who needs the till to work right now without reading a manual. That framing comes straight from the product's own homepage, because it is genuinely how the feature set was decided.

Building it as a browser application raised the specific problems we had to solve before the product could be taken seriously by a working shop:

• Hardware without lock-in - a browser cannot natively talk to a USB receipt printer or fire open a cash drawer, so we had to bridge that gap while still letting retailers source every piece of hardware from any supplier.
• Cash you can trust - a till that handles physical cash needs an audit trail for every event: opening floats, cash in and out, no-sale drawer openings, refunds, and voids, all reconciled at the end of each day.
• Multi-shop isolation - one company account has to run several locations, yet an employee at Shop A must never see or touch Shop B's transactions, stock, or reports, and that isolation has to be enforced at the server level rather than hidden in the interface.

The Approach: A Till Built Around the Trading Day

Rather than starting from a feature list, the product is structured around the actual shape of a retail day, and the documentation walks through it in the same order a shop would live it.

• Opening the day - each terminal has its own POS day cycle. Sales are blocked until the day is opened with a recorded opening float, so there is never a transaction that belongs to no trading session.
• PIN login for staff - employees sign in with a 4-digit PIN rather than an email and password, because a queue at the counter does not wait for typing. Every session is recorded with a start time, end time, and a full activity log.
• Switching users mid-shift - one cashier can hand the till to another without losing the cart in progress. This exists because shift changeovers happen mid-transaction in real shops, not between them.
• Breaks that count themselves - staff clock breaks in and out on the till, and work time is calculated with break minutes excluded, which feeds directly into the payroll report.
• Closing the day - the closing routine asks for a counted float, shows the expected-versus-actual discrepancy immediately, and produces a printable Z-report for the session.

Checkout Built for Speed

The selling screen is where a POS earns or loses its keep, so it carries the densest set of decisions in the product:

• Instant product search - search by name or SKU runs locally for speed, while barcode queries hit the server for an exact lookup. USB and Bluetooth barcode scanners work out of the box with no drivers or extra setup.
• Variants without limits - a product can carry unlimited variants (size, colour, weight), each with its own price, SKU, barcode, and stock count, which is what makes the system usable for fashion and clothing retailers.
• Discounts with a reason - percentage or fixed-amount discounts apply to the cart, with an optional reason field, so a generous Tuesday does not become an unexplained hole in the day's figures.
• Quick sale - a one-off item can be sold with a custom name and price, no product record needed, because real shops sell things that were never put in the catalogue.
• Payments in one transaction - cash with automatic change calculation, card, and mobile can all be taken, and a saved customer can be attached to the sale for a full purchase history.
• No sale, still logged - opening the drawer without a transaction is possible but always recorded, which closes one of the oldest gaps in retail cash control.

Inventory With a Paper Trail

The inventory side is designed around a single principle: every unit of stock that moves should leave a record of who moved it, when, and why.

• One catalogue, many shops - products are defined once at company level and shared across all shops, but each location controls its own stock counts, can override the selling price, and can switch a product off entirely without affecting the other shops.
• Purchase orders with a full lifecycle - orders move through Draft, Ordered, Partial receipt, Received, and Cancelled states, with partial deliveries updating stock automatically as they arrive.
• Suppliers as first-class records - contact details, VAT number, payment terms, and the full purchase history live against each supplier, so reordering is a lookup rather than a memory test.
• Adjustments that explain themselves - manual stock changes require a reason: wastage, damage, theft, expired, or correction. The vague "stock just went down" entry does not exist in this system.
• A complete movement log - every change, whether a sale, a purchase order receipt, or a manual adjustment, is logged with the user and a timestamp, filterable by product, type, and date.
• Low stock thresholds - each shop sets its own thresholds, and items approaching zero are flagged on the till itself, where the person who can act on it will actually see it.

Cash Control and End-of-Day Reporting

Cash handling is where browser-based POS products usually feel flimsy, so this area got disproportionate attention. Cash added to or removed from the drawer outside of sales, for example a float top-up or a safe drop, is logged as an audited cash movement. At close, the counted float is entered and the discrepancy against the expected figure is shown immediately, not discovered a week later in a spreadsheet.

The Z-report generated for each terminal's day covers total sales, the split by payment method, discounts, refunds, voids, and all cash movements, with a VAT breakdown built in. Tax handling supports both price-includes-VAT and price-excludes-VAT models, configured per shop through tax profiles and tax rules, which matters for retailers operating across different pricing conventions. Reports export to PDF from the transaction history, where individual sales can also be refunded, voided, or reprinted.

Staff, Permissions and Payroll

Reddy Till ships with 11 granular staff permissions covering selling, product management, report viewing, inventory, opening and closing the till, and employee administration. The decision behind granularity is trust with boundaries: a weekend cashier can sell and nothing else, a floor manager can receive stock but not see the payroll report, and the owner decides exactly where each line is drawn.

Because every PIN session is tracked with clock-in and clock-out times, the system produces a per-employee payroll report with total work minutes per session and break time already deducted, organised by pay cycle. Hours tracking is not a bolted-on module; it falls out of the same session data the till already keeps for security.

Workflow and Integrations

The hardest integration problem in the product is physical: browsers are sandboxed away from USB devices by design. Reddy Till solves this with POS Bridge, a small local application installed on the till machine that handles communication between the browser and the USB receipt printer and cash drawer. The retailer sources both from any supplier; there is no approved-hardware list and nothing to buy from us.

Bringing a new till online is deliberately short. An 8-digit single-use pairing code is generated from the admin dashboard and entered on the public terminal pairing page. Each terminal is registered to one specific machine and remembers its hardware setup; if the machine is replaced, the terminal is re-paired in a couple of clicks and nothing is lost, because every transaction and stock record lives server-side rather than on the till. The homepage claims the first terminal can be paired in under five minutes, and the pairing flow is public, so you can judge that claim yourself.

Around the core system sit the pieces that make it operable without hand-holding: separate admin and employee login paths, per-shop timezone configuration so a company can run shops in different regions with all times shown in local shop time, and a full public documentation site covering everything from first login and VAT setup through to troubleshooting a printer that will not print and re-pairing a disconnected device.

Technical Implementation

Reddy Till runs on the same stack as our other in-house products, and for the same reason: a POS needs mature, boring, dependable foundations more than it needs novelty.

A Pricing Model With Nothing Gated

The pricing page is a product decision in itself, and the site describes it as "simple, honest pricing" for a reason: every plan includes every feature. You pay for the number of shops, never for access to parts of the system. There is no tier where purchase orders, payroll reports, or the audit trail become an upsell.

• Starter, 49 euro per month - one shop with one terminal included, every feature, priority support.
• Growth, 99 euro per month - three shops with one terminal per shop included, every feature, priority support.
• Enterprise, custom pricing - more than three shops or specific requirements, with agreed shop and terminal counts plus dedicated setup and onboarding.

Additional terminals cost 30 euro per terminal per month on any plan, and every plan carries unlimited products and unlimited staff. We priced it this way because feature-gated POS pricing punishes exactly the small retailers the product is for.

Results and Outcome

Reddy Till is live, taking terminal pairings, and publicly documented. What you can verify today: the full product at reddytill.webwizard.ie, a documentation site with more than thirty guides running from first login through troubleshooting, a public terminal pairing flow, separate admin and employee login paths, and three published pricing tiers. The system covers six feature areas, enforces 11 staff permissions, and supports unlimited terminals across multiple shops under a single company account.

Reddy Till is our own product, so there is no client outcome to report and no third-party testimonial to quote. We publish no user or revenue figures for it, and we do not invent numbers: everything claimed on this page is observable on the live application and its documentation.

For prospects evaluating us, the outcome that matters is simpler: this is what our custom web application work looks like when we are both the client and the builder, from data model and permissions design through to hardware integration, documentation, pricing, and operations.

Frequently Asked Questions

See More Related Work

• Poisa - Sales and Payment Management - another in-house Django SaaS product, focused on sales and payment tracking for small businesses.
• Finafy - Accounting Workflow - our in-house accounting application, built on the same stack and product philosophy as Reddy Till.
• Custom Web App Development - scope, pricing and timelines for a build like this.