The counter, end to end
Ringing up and taking payment, keeping selling when the line drops, printers and the drawer, cash-up, the back office, the reporting, running a fleet of tills. Proven on counters that are open right now.
The platform
One engine. Every counter gets what only it needs.
Most till suppliers have one product with a settings screen, or a fork per customer that slowly rots. Phlo POS is a shared engine with places to hook into. What is yours stays yours; what turns out to be useful to everyone goes back into the engine, where it is maintained for everyone.
Most of your till is already written
That is the whole point of a shared engine, and it is what makes a bespoke till affordable. Two counters we run, and what each of them actually had to have built.
Its loyalty scheme and its own reports
Three things had to be built: the loyalty programme it has run for years, the columns its head office wants in a report, and which screen layout its tills use. Multi-currency, multi-store and the cash procedures were already there.
Tabs, which nobody had asked for yet
Rounds parked on a name, a table or a team, picked up by whoever is behind the bar. It was built because one counter needed it, and written so the next one can simply switch it on.
That is the bargain. You pay for the part that is yours, and the part that is shared keeps getting better without you paying for it twice.
How a custom till is actually built
Not by copying the engine and editing it, which is cheap once and expensive forever. By hooking your own behaviour into it at the moments where a counter differs, and leaving the rest alone.
Your rules, at the moments that matter
What blocks closing the day. What must not be cancelled. What happens the moment a receipt is booked. What extra fields a line carries. What a discount is allowed to do. Each of those is a place where your behaviour runs, and where doing nothing means the engine behaves as it always does.
Your words, on screen and on paper
What tax is called in your country, how a discount line reads, what goes at the bottom of the receipt, how many copies a card payment prints. A receipt in the Caribbean splits tax three ways under three names; that is a hook, not a fork.
Your systems, connected
A loyalty programme with its own broker, a bookkeeping export with your ledger rules, a product feed from a system that predates all of this. Connectors are ordinary code in your own layer, and they get the same tests as everything else.
Your data model, extended
An extra column on a receipt line, an extra table, an extra kind of line the till may book. Your layer adds fields to a model rather than copying it, so a shared field is still updated in one place.
Wondering which part of your counter would be a hook and which part is already there? That is what an intake answers.
The rule that keeps custom work from getting expensive
"Demonstrably reusable functionality belongs in the shared engine, even when one client is the first or only taker."
From the working agreements of the Phlo POS engine
It sounds like an internal detail. It is the whole economics of the thing. The easy way to build a custom till is to copy the engine and change it, which is cheap once and expensive forever: every fix has to be made five times, and four of them get forgotten.
So the tab system a bar asked for is written to be general. The multi-currency handling a chain needed is in the core. The terminal protocol we implemented for one bank sits next to the cloud terminal as an equal. Every counter that comes after starts further along than the one before, and that is why the second project of a kind costs less than the first.
What makes it safe to change
A shared engine is only an advantage if a change for one counter cannot quietly break another.
Both installations run before anything ships
Every till and every back office of every live installation is started and checked by the test suite. If one of them stops working, the change does not go out.
The maths is tested against golden files
Totals, tax, discounts and rounding are checked against recorded outcomes. Booking and cancelling are tested against a real database, because that is where money bugs live.
The database cannot drift
A test rebuilds the whole schema from its migrations on an empty database and compares it, column by column, with what is actually running. A development shortcut cannot become a production surprise.
Deploying is deliberate
Per counter, with the version raised on purpose. The receiver takes a dump first, runs the pending migrations, and rolls everything back automatically if the health check fails.
Old agents keep working
The contract between the till and the machine it prints on is frozen in writing. New abilities are added beside it, never in place of it, so a counter that has not been touched in a year keeps printing.
Problems have an address
A report button on the till and in the back office sends a screenshot with the circumstances and opens a thread. What was reported, what was decided and in which version it was fixed is written down, not remembered.
Questions people ask before they commit
Do we get the source code?
You get a system that runs, and an agreement that says what happens if we are hit by a bus. What we do not do is lock you into hardware you can only buy from us or a licence that stops your till when a contract ends. Ownership of the work we do for you is part of the proposal, not an afterthought.
What if we want something the engine does not do?
That is the normal case, and it is the reason for the hook contract. Something specific to you lives in your own layer; something any counter could use goes into the shared engine, where it is maintained and tested for everyone. You do not pay twice for the same idea.
Does a change for another customer break ours?
It is not allowed to. Every change to the shared engine runs the full suite of both live installations before it ships, and deploying to a counter is a deliberate step per app, with a database dump taken first and an automatic rollback if the health check fails.
How do you know the money is right?
The calculation kernel is tested against golden files, and the booking and cancelling flows are tested against a real database rebuilt from the live structure. Cancelling a sale used to be the bug factory; it now has tests that book, cancel and check the aftermath.
Can it talk to what we already run?
That is most of the work in a chain. Bookkeeping exports, loyalty programmes, product feeds and older databases that cannot be replaced overnight are connectors, and a connector is code we write and you keep.
What does a Phlo POS project cost?
A custom till has no list price, because the scope decides it. After an intake you get one price for the whole project: build, hardware advice, installation and training in a single amount, agreed before we start.
Ready to look at it properly?
What would your counter need?
Tell us how you sell today and what gets in the way. You get a fixed scope and a fixed price, or an honest no.
What an intake looks like
- Counter
- Bar with a kitchen, two screens
- Today
- A till that stops when the line drops
- Hardware
- Existing touchscreen and printer
You hear back from the people who would build it, not from a sales desk.