Built because the alternative wasn't good enough.
Ruby POS exists because most point-of-sale systems available to Kenyan businesses were built for somewhere else. They assumed reliable internet, assumed no mobile money, assumed a business would adapt to the software rather than the other way around. So we built one that doesn't make those assumptions.
A product built from frustration, not ambition
Ruby POS did not begin as a business plan. It began as a pattern. Shop owner after shop owner, describing the same set of problems. Stock going missing between branches. M-Pesa payments that had to be matched to receipts by hand. A till that stopped working the moment the internet flickered, and a day's sales that disappeared with it.
By 2021, Merut Tech Solutions had spent two years building custom systems for businesses across Kenya — POS platforms for mini-marts, ERPs for distributors, payment integrations for hospitality groups. Every project taught us something. Every client showed us a variation of the same frustration. Over time, the pattern became impossible to ignore: the tools that existed were either too expensive, too rigid, or too fragile for the way Kenyan businesses actually operate.
So we made a decision. Rather than continue building one-off POS systems for each new client, we would build a single platform that could be adapted to almost any retail context — and release it as a product. Not a foreign import with localisations bolted on. Not a stripped-down version of an enterprise system. A point-of-sale platform designed, tested, and supported from Nairobi, for the operating reality of East African businesses.
The first Ruby POS deployment went live in 2022, in a pharmacy in Nairobi with three tills and one very frustrated owner. Within a year, the same system was running in mini-marts, boutiques, restaurants, and electronics shops across four Kenyan counties. The pattern that had started it was now the foundation of the product. Offline-first architecture. Native M-Pesa and Airtel Money. Multi-branch stock visibility. A business website bundled in, so no shop would ever need to run a separate system just to sell online.
Today Ruby POS runs in hundreds of businesses — from single-counter kiosks to chains with more than a dozen locations. The engineering team that built it has grown from three to a distributed group across Nairobi, Kisumu, and remotely abroad. The product has picked up capabilities we couldn't have imagined when we started: statistical demand forecasting, automated reconciliation, cross-branch transfer tracking, and a customer-facing website that syncs stock straight from the till.
What has not changed is the founding assumption: the software should adapt to the business, not the other way around. Ruby POS exists because Kenyan businesses deserved a point-of-sale system built for Kenya — one that assumed the internet would fail, mobile money would dominate, and every shop would eventually want to sell online. Those assumptions are no longer features. They are the baseline we hold ourselves to.
The two disciplines behind Ruby POS
Ruby POS is a product of Merut Tech Solutions. Two distinct teams within the company shape what the product becomes.
Engineering & Product
The build sideEverything you see on a Ruby POS till — the checkout flow, the offline queue, the M-Pesa integration, the branch dashboard — is built by a small team of senior engineers working out of Nairobi. They write the code, run the tests, and sit on the support calls when something doesn't behave as expected.
The team's particular obsession is resilience. Ruby POS assumes things will break: the internet drops mid-sale, the printer runs out of paper at the wrong moment, a payment gateway sends a delayed confirmation. Rather than pretending these don't happen, we design every flow to survive them.
They also own the technical roadmap — the parts of the system that aren't visible to users yet but will matter in twelve months: better forecasting, faster sync, tighter security, and the quiet infrastructure work that keeps everything running smoothly at scale.
Deployment & Support
The hands-on sideRuby POS is not a product you download and configure yourself. Every deployment is handled by a team who installs the hardware, configures the till, imports your existing stock file, and trains your staff on the system before it goes live.
They also stay on after launch. When a shop calls because the till isn't printing or a payment hasn't confirmed, it's this team on the other end of the line — not a call centre, not a chatbot. Real people in Nairobi who know the product and know most of our clients by name.
Their work shapes the product as much as engineering. When three clients in a month report the same confusion about a button, the button gets redesigned. Support feedback is the shortest path we have to improving Ruby POS.
Most POS systems are built for the shop the developer imagined. We built ours for the shop the shopkeeper actually runs — one with a power cut on Tuesday, a stock delivery that doesn't match the invoice, and a customer paying half in cash and half on M-Pesa.Methuselah Misati · Engineering Lead, Merut Tech Solutions
Four convictions that shape every release
Assume the network will fail
Ruby POS was designed offline-first, not offline-as-a-fallback. The till stores every sale locally, queues payment confirmations, and reconciles them the moment the connection returns. Cash sales always work. Card and mobile money work as soon as the network does. Nothing gets lost in between.
This is not a feature we advertise as remarkable. It is the minimum standard a POS system in Kenya should meet, and the fact that most don't is a symptom of where they were built.
Every payment method, one counter
A customer walking into a shop in Nairobi might pay by M-Pesa, Airtel Money, bank card, cash, or a mixture of all three. The till should not care. Ruby POS accepts all of them from the same interface, records them the same way, and reconciles them into the same end-of-day report.
We treat payment flexibility as a design requirement, not an integration checklist. If a new wallet becomes dominant in the market, adding support for it is a matter of weeks, not a re-architecture.
A shop, not a module
Most POS systems are sold as the base product, with websites, loyalty, analytics, and stock forecasting sold separately. We chose the opposite approach. Every Ruby POS comes with a business website, a stock system, staff management, and reporting already included.
The reasoning is simple: a small business owner should not be paying for four subscriptions to run one shop. The product should solve the whole problem, at a price that reflects what it would cost them to solve it four times separately.
Built in Nairobi, supported in Nairobi
Ruby POS is developed by Merut Tech Solutions, headquartered on Thika Road. Every deployment is done by our team. Every support call reaches our staff. Every update is built on a product roadmap shaped by the businesses we serve directly.
This is not a marketing position. It is an operating choice with real costs — we scale more slowly than a purely remote product would, and we cannot avoid the realities of running a team in Kenya. In return, we ship a system that actually fits the businesses using it, and we answer the phone when something goes wrong.
Ruby POS is built by Merut Tech Solutions.
Merut Tech Solutions is a Nairobi software company founded in 2019, before the pandemic reshaped how businesses operate. The company builds custom software, ERP platforms, payment integrations, and business intelligence systems for clients across Kenya and beyond. Ruby POS is its flagship product — a point-of-sale platform refined over more than five years of deployments, feedback, and iteration.
Working with Merut's wider team gives Ruby POS two things a standalone product company could not easily replicate: a constant supply of real client situations that reveal what needs to change next, and an engineering bench deep enough to handle the harder problems — statistical forecasting, cross-branch data pipelines, complex payment orchestration, and the kind of unglamorous infrastructure work that makes everything else stable.
If you're curious about the parent company, the wider portfolio, or the people behind both Merut and Ruby POS, that story lives on the Merut site.
What Merut brings to Ruby POS
- Custom engineering depth. Ruby POS inherits patterns and libraries from hundreds of bespoke client projects — most of which are too complex for a POS product to need, but all of which taught us something.
- Data & analytics capability. The forecasting, dashboards, and reporting tools inside Ruby POS were originally built for Merut's ERP clients. They now ship as standard features.
- Payment integration maturity. Years of working with M-Pesa, Airtel Money, card gateways, and bank systems means the Ruby POS payment layer is battle-tested under conditions most products would not survive.
- Hardware supply & support. When a Ruby POS client needs a terminal, printer, or scanner, the same team that supplies hardware to Merut's ERP clients handles delivery and setup.
- A single support line. Ruby POS support and Merut support share the same team. One call reaches the people who actually built and deployed the system.
Six principles we hold Ruby POS to
The last 5% matters most
Any POS system can handle a straightforward sale. The one that matters is the sale that goes sideways — the payment that doesn't confirm, the printer that jams, the customer who walks out halfway through. That is where trust is earned.
Speed is a feature
At a busy counter, every extra second costs a sale. We measure the number of taps between a customer saying "I'll take it" and the receipt printing. Everything that doesn't reduce that number is optional.
Owners should see the whole shop
A business owner should not have to be physically present to know what's happening. Sales, stock, staff activity, cash flow — all of it should be on their phone, updated live, without needing to log into a desktop.
Data belongs to the client
Every sale, customer record, and stock movement stored in Ruby POS belongs to the business using it. Export it, migrate it, back it up, or move it to another system — the data is yours. We don't hold it as leverage.
Boring technology, carefully applied
We choose tools that have stood up to production use for years. The PHP version running your till is not the bleeding edge of what's possible — it is what will still work in five years, on hardware that costs what a small business can afford.
Support is a product feature
How fast we answer the phone, how well the person on the other end knows your shop, and whether the fix actually solved the problem are all as important as what the till does. We measure both equally.
See what Ruby POS could do for your shop
Book a free 30-minute demo. We'll walk you through the system with your business in mind — inventory, payments, staff, whatever matters most to you. No pressure, no jargon.