Operations · POS and retail systems
We build point-of-sale (POS) and retail systems: the till, the stock behind it, and the back office that sees every branch. It is for shops and retail chains whose off-the-shelf POS no longer fits how they sell. It is fixed-scope work, so you get one number before it starts.
The problem
A till looks simple until the connection drops during a busy hour. Sales still have to go through, stock still has to come down, and when the line comes back, two branches may have sold the last unit of the same item. Add returns, voids, the cash-up at the end of a shift, and staff who should not be able to issue refunds, and most of the work is in what happens around the sale, not the sale itself.
None of these? Selling online to the public rather than across a counter? See multi-vendor ecommerce.
| Till app | Sales, discounts, returns, voids, receipts |
|---|---|
| Offline sales | Saved on the device, sent when the connection returns |
| Products and pricing | Catalogue, barcodes, branch prices, promotions |
| Stock | Levels per branch, transfers, counts, low-stock alerts |
| Branches | One back office for every location |
| Staff and permissions | Who can sell, refund, void or discount |
| Shifts and cash-up | Opening float, end-of-shift totals, differences recorded |
| Reports | Sales by branch, product, staff member and day |
What makes this one hard
The stock count has to survive a dropped connection.
An offline till keeps selling from what it last knew. When it reconnects, its sales meet everyone else's, and the system has to decide what the stock really is. Those rules are written down during scoping, not discovered in a branch: which sale counts first, what happens to an item sold twice, and who is told.
Live · FindWorker
FindWorker is ours, and its console is where we manage users, orders, money and disputes. A retail back office asks the same questions: who can see which numbers, who can change them, and where the money went.
Read the The admin console behind every platform we run case study
Most projects fail before any code is written — because a price was given before anyone knew what it would cost to build.
If we can't answer these, we quote a phase, not a platform.
Price and phases
One number, before it starts.
Fixed-scope work is scoped first, quoted second, built third. You own the code on payment, and a defect costs you nothing.
Does it work offline?
Yes, if we scope it to, and for a till we almost always do. Sales are saved on the device and sent when the connection returns. Three things need deciding first: which actions work offline, since a sale usually can but a refund may need a manager online; how card payments behave without a connection, which depends on your card terminal and provider; and how stock is settled when offline tills reconnect.
Can it run several branches?
Yes. Each branch has its own tills, stock and staff, and the back office sees them together or one at a time. Three things need deciding: whether prices and promotions are set centrally or per branch; whether stock can move between branches, and who approves it; and whether a manager in one branch can see another. We settle these during scoping, because they change the data behind every screen.
Can it connect to our online store?
Usually, but it depends on the store. Three things decide it: whether your store platform has an API, a documented way for two systems to share stock and orders without retyping; whether the shop and the site share one stock count or keep separate ones; and which system wins when they disagree. We check your store during scoping and name the connection in the quote, or tell you plainly that it can't be done well.
Will it work with our barcode scanners, receipt printers and card terminals?
It depends on the exact devices, so we check them before we quote. Many barcode scanners behave like a keyboard and need little work. Receipt printers and card terminals vary by model, and by whether the maker publishes a way for software to connect to them. Send us the model names, or tell us you have not bought hardware yet, and we will name any device we cannot support before you commit.
Can we control what each member of staff can do?
Yes. Roles are set in the back office: a cashier sells, a supervisor can void or discount, a manager can refund and close the till, and an owner sees every branch. You decide where those lines sit, and they can differ by branch. Every refund, void and price override records who did it and when, so the end-of-day numbers can be explained.
How is a POS system priced?
As fixed-scope work: one number, before it starts. Scoped first, quoted second, built third. The scope names the tills, branches, devices and connections in the build, and lists what we are not building. Anything you add later is priced before it is built, and you decide whether it goes in. A defect costs nothing. The number comes from your scope, which is why we don't publish a price list.
Can you replace the POS we use now?
Yes, but the switch needs planning as much as the build. Three things shape it: whether your products, stock levels and sales history can be exported from the current system; whether branches move over together or one at a time; and how long the old and new systems run side by side. We look at what you have during scoping, and tell you if fixing around your current POS would cost less than replacing it.
Who owns the code?
You do, on full payment. Exclusive and perpetual.
What if you disappear?
Your repository, your accounts, your signing keys. Documented so another team can pick it up.
Can we move to another team later?
Yes. We write the handover documents that make that possible, whether you use them or not.
Do you take equity instead of cash?
No.
Who holds the app store accounts?
You, unless you ask otherwise. Decided at kickoff, not at launch.
What happens to our data?
It is yours. Exportable at any point, in a format another system can read.
Other operations we build
No call. A few guided questions, then a tailored quote — usually within one business day.
Or send us the idea in three sentences on WhatsApp, or email support@codingwitht.com.