Custom software
Most software firms show you logos. We'd rather show you a system: roughly 250 database objects, seven services, an offline sync engine, a promotions engine that runs in the aisle, and computer vision on a mid-range Android handset — all of it in production. That's the standard your project gets held to.
01 · What we build
We're at our best when the requirement contains a word like "offline", "reconcile", "audit trail", "on-device", "multi-tenant" or "it has to still be right in three years".
02 · How we work
These aren't values on a wall. They're the working rules that produced the platform, and they're the ones we'd bring to your project.
If a requested feature is going to hurt you in month nine, you'll hear that before it's built, with the reasoning. A supplier who only agrees is a supplier who's letting you pay for their silence. Several of the best decisions in our own platform are things a client asked for and we argued against — and some are things we were wrong about.
"150 ms inference" means we measured it on a real handset, not that a benchmark suggested it. Before a single line of voice was integrated, the engine was proven on the exact stack in an isolated branch. If we haven't seen it work, we don't say it works.
We rejected the best-known PDF library and the best-known object detectors because both are AGPL and that reaches your deployment. We took the accuracy and effort hit instead. A licence problem discovered during due diligence is not a problem you want.
If a business rule will change, it becomes data. Our claims engine handles nine distinct scenarios and a tenth costs one row in a master table — not a release, not a change request, not a call to us. The measure of a good build is how rarely you need us after it.
AR planogram overlays and hard predictive-restock percentages were researched and rejected as vapour. Our report builder isn't called "AI powered", because it's a deterministic query engine. The list of what we refused is part of the specification.
03 · Evidence
Every claim on this site points at something running. If you want to interrogate the engineering, this is the shortest path: pick a hard problem below and ask us how it works.
| Problem | What most teams do | What we did |
|---|---|---|
| Offline field data | Cache a few screens and hope; fall back to the server on read. | Ship a filtered database per person. Reads never touch the network — enforced as an architectural rule, not a preference. |
| Sync conflicts | Last-write-wins, then reconcile by hand at month-end. | Client-generated identity, deterministic keys for shared rows, upsert on re-send. A lost reply costs nothing. |
| Orphaned records | Retry loops and a nightly cleanup job. | Post the whole object graph in one transaction, parents first. The failure class is deleted, not managed. |
| Stock that disagrees | Write balances from both sides and reconcile the difference. | Append-only ledger; balances are replayed. Each row records that it was applied, in the same transaction. |
| Shelf recognition | Upload photos to a cloud vision API and bill per scan. | Detect and embed on the device. Zero cost, works in flight mode, and a new SKU needs photos rather than a retrain. |
| Schema change on 500 phones | Force an app update and a full re-download. | The device migrates its own tables on open. The change lands with no reinstall and no support call. |
Reference material. Our own platform is the reference: the live portal, the signed Android build, and the architecture behind them. We're happy to walk an engineer on your side through any of it — including the parts that went wrong first.
04 · Fit
Both lists are honest. Hiring the wrong firm is expensive for you and miserable for us, so it's worth thirty seconds now.
The system has to work offline, or reconcile money, or survive an audit. There are multiple entities, roles or tenants with genuinely different rules. Someone has already tried and it didn't hold up. Or the brief is simpler than any of that and you just want it built properly — by people who'll argue with you when you're wrong and hand you source you can walk away with. The hard part doesn't have to be exotic. It has to be real.
You want something that can't be built right — a shortcut that breaks the architecture, a number reconciliation won't honour, a corner cut on the audit trail, or a "yes" to a design that will quietly fail your users a year from now. Those we turn down, in writing, with the reason. But if it's logically possible and holds the architecture, we can build it — and we'll back ourselves on price and quality against anyone in the market. A small budget isn't a poor fit: tell us what you have and we'll tell you honestly what it buys, then start with the piece that earns the rest.
Next
Not the feature list — the constraint that makes it difficult. That's the conversation worth having, and it's usually the one that decides whether the project works.