Six systems, running every day.
Client names, client figures and client data stay confidential - permanently, and without exception. What we can tell you is the problem each business actually had, the engineering decision that solved it, and what changed afterwards. That is the part worth reading anyway.
The case studies
Replacing a point of sale that could not count
The problem
A busy retail and wholesale shop was running on a commercial package that stored money as a 32-bit floating point number. Outstanding balances had drifted into fractions of a cent, bills were landing a cent over the total of their own lines, and nobody trusted the margin report enough to act on it. The shop had been working around its own software for years.
What we built
We rebuilt it on an integer-cent double-entry core, where every sale writes a document, journal lines and stock movements inside one transaction, and where a journal that does not balance simply cannot save. Along the way the migration surfaced something nobody had noticed: not one item in the catalogue carried a usable wholesale price, so every trade bill had been raised off the retail shelf label - which carries a discount buffer, and was therefore overcharging trade customers substantially. We built a pricing engine that derives the trade price from cost instead, in exactly one place in the code, so no screen can ever resolve a price a different way.
At a glance
- Domain
- Retail & wholesale POS
- Users
- Counter staff, stockroom, owner
- Core
- Integer-cent double-entry ledger
- Hardware
- Thermal receipt, label printer, scanner
- Deployment
- On the shop machine, offline-first
- Migration
- From a commercial package
What changed
- Money arithmetic is exact; balances no longer drift and bills add up to their own lines
- A pricing error affecting the entire catalogue was found and corrected during migration
- Cost is never shown in digits on a customer-facing screen - it appears in a cipher
- A dead printer no longer stops a sale; the bill is in the books before paper is attempted
- Automated tests replay a full week of trading against the books on every change
An audited fund, rebuilt from a desktop day book
The problem
Years of loans, savings, tills and cash movements lived in an ageing desktop database with no real ledger behind it. Reports disagreed with each other depending on which screen you asked, the cash-in-hand figure had never existed as a stored number at all, and preparing for the annual audit meant a fortnight of manual reconstruction.
What we built
We rebuilt the whole book as proper double entry - a chart of accounts, a journal that refuses to save unless it balances, and posted documents that can only be reversed rather than edited. Then we proved it: the migration was held to the standard of reproducing every line of the audited year-end accounts, to the rupee, including the cash figure the old system had never held. The build refuses to package itself if that reconciliation stops passing, so a database that no longer agrees with the audited accounts physically cannot reach the machine it runs on.
At a glance
- Domain
- Loans, savings & day book
- Users
- Fund officers, committee
- Core
- Double-entry ledger, append-only
- Proof
- Reconciled to audited accounts
- Deployment
- Zero-install Windows package
- Migration
- From a desktop database
What changed
- Every balance-sheet line of the audited year-end accounts reproduced exactly, to the rupee
- A cash-in-hand figure now exists and is derived, rather than being reconstructed by hand
- Trial balance, income and expenditure, and balance sheet all derive from the same journal
- Ships as a self-contained folder carrying its own runtime - nothing to install on the machine
- Updates replace the program folder and structurally cannot touch the data folder
A duty engine that shows its working
The problem
Importers were guessing at landed cost. The statutory duty cascade is genuinely hard - each charge computed on a different base, some of them on each other - and the published tariff is a maze of chapters, notes and exceptions that change by gazette. The existing tools gave a number with no explanation, which is useless the moment an officer questions it.
What we built
We built a classification and duty platform that computes the full statutory chain and names the base behind every single line. Classification takes a plain-English product description and returns a code with the reasoning attached - and, just as importantly, why the runner-up was rejected. The engine is grounded in the actual chapter and section notes rather than in a keyword guess, and it is built to say “I am not confident” and show candidate headings rather than assert a code it cannot defend. Every rate carries a valid-from and valid-until date, so when a gazette lands mid-year the old rate survives as history and a declaration from last quarter still recomputes correctly.
At a glance
- Domain
- Tariff, duty & compliance
- Users
- Importers, clearing agents
- Core
- Rule engine over the full tariff
- AI
- Grounded classification with citations
- Deployment
- Web platform, managed Postgres
- Demo
- Try a simplified version
What changed
- Full cascade computed with the base named on every line, so any figure can be defended
- Classification returns the reasoning and the rejected alternative, not just a code
- Refuses to state a figure it cannot ground - low confidence shows candidates instead
- Rates are dated and versioned; a gazette adds history rather than overwriting it
- Landed cost carries through to a per-unit figure and into the shelf price
Many suppliers, one container, one honest loading list
The problem
Consolidating goods from dozens of factories into a single container meant reconciling dozens of packing lists in dozens of formats - different column names, different units, marks that only made sense to the person who wrote them. The master loading list was assembled by hand every time, and an error in it is not discovered until the container is opened at the other end.
What we built
We built the pipeline that turns source packing lists into an intake register and then into a master loading list, with the arithmetic checked at every hand-off: cartons in must equal cartons out, weights must reconcile, and every mark must resolve to a known consignee. Where a source document disagrees with itself, the system stops and shows the two figures side by side rather than silently picking one. Landed cost then flows from the container back down to each item, so the shelf price is built on what the shipment actually cost.
At a glance
- Domain
- Consolidation & shipping
- Users
- Warehouse, documentation, management
- Core
- Reconciliation pipeline
- Inputs
- Spreadsheets, scans, photos
- Output
- Master loading list & document pack
- Scale
- Container-level, many suppliers
What changed
- Carton and weight reconciliation enforced at every stage, not checked at the end
- Conflicting source figures surfaced side by side instead of being silently resolved
- Master loading list generated from the parts rather than retyped
- Landed cost apportioned back to individual items, to the exact cent
- Document packs assembled per shipment and exported ready to submit
Finding the 7% that was never really there
The problem
A manufacturer priced its products from a costing sheet that folded estimated monthly overheads - a guessed electricity bill, a share of wages - into the material cost of every unit produced. The same salaries were then entered again as a monthly expense. The same money was being counted twice, and it made every product look roughly 7% more expensive to make than it actually was. Pricing decisions and quotes had been built on that number for years.
What we built
We separated the two things properly and enforced the distinction in the data model rather than in a policy document: material cost is only what a supplier actually charged for materials, plus the duty and clearing on them. Everything else - salaries, electricity, rent, transport, repairs - is an expense, and an expense can never be posted as material. Entry was reduced to one plain question (“what happened?”) with the accounting worked out underneath, so a floor supervisor can record a production run correctly without knowing what a journal is.
At a glance
- Domain
- Manufacturing costing
- Users
- Floor supervisor, owner
- Core
- Cost model with enforced separation
- Access
- Desktop plus phone on the works wifi
- Deployment
- On-premises, offline-first
- Migration
- From spreadsheets
What changed
- Double-counted overhead removed; true unit cost established and defensible
- The material/expense distinction enforced structurally, so it cannot drift back
- One monthly result page the owner reads in ten seconds
- Production entry simple enough for the factory floor, correct enough for the books
- Margin measured per product, per customer and per month against the intended price
Finding the invoice nobody remembers the name of
The problem
Thousands of packing lists, invoices, bills of lading, certificates and customs declarations spread across years of folders - in PDF, Word, Excel, and a great many as phone photographs of paperwork. Several times a week somebody needed an answer that existed somewhere in those files, and the only way to find it was to open folders one at a time. The searches that mattered were never for a filename; they were for what a document was about.
What we built
We built a local search tool with a hotkey overlay: hybrid retrieval fusing full-text and semantic search, so a container number or an HS code still lands as the top hit while a vague description also works. Scans and photographs are OCR'd so their contents are as searchable as typed text. Every result cites its file, page, sheet and cell along with the matching snippet, and where confidence is low it shows candidate documents instead of asserting a figure - because a wrong number stated confidently is worse than no answer, once somebody repeats it. It runs entirely on the machine; nothing leaves the building by default.
At a glance
- Domain
- Document search & OCR
- Users
- Operations, documentation
- Core
- Hybrid retrieval - keyword + vector
- Privacy
- Local by default
- Inputs
- PDF, DOCX, XLSX, JPG, PNG, scans
- Access
- Global hotkey overlay
What changed
- Searchable by content, including inside scans and phone photos of paperwork
- Exact tokens - container numbers, HS codes, part numbers - reliably land top
- Every answer cites file, page and snippet, and is clickable straight to the spot
- Refuses to assert a figure it cannot show you the source for
- Fully local; cloud assistance is an explicit, visible opt-in that sends snippets only
What these projects had in common.
Six very different businesses. The same three things were true in every single one of them.
The real problem was not the one described
Every brief we have been given described a symptom. The wholesale price that did not exist, the overhead counted twice, the cash figure that had never been stored - none of those were in anybody's requirements document. They were found by sitting with the business and reading its actual books.
The migration was the hard part
Writing new software is the easy half. Getting years of existing records across faithfully - and then proving to the owner that the old totals and the new totals agree, line by line, before anybody is asked to trust it - is where the real work sits.
Correctness had to be structural
A rule written in a manual gets broken by the third month. The same rule enforced by the data model - a journal that cannot save unposted, an expense that cannot be recorded as material, an update that cannot reach the data folder - simply holds, permanently, with nobody having to remember it.
What is your business working around today?
There is usually one report nobody trusts, one number that gets recalculated by hand every month, or one thing everybody knows is wrong but has stopped mentioning. That is where these projects start.