Work
Client work is anonymised. Each case says what was wrong, what we built, and what changed. Then the six products we own.
Vernier, in production
The nine systems below are parts of Vernier, running in production. Together they check sales, stock, supply chain, labour, people, repairs, property and finance against each other, and Vernier is not tied to an industry. It connects the data an organisation already has, checks each source against the others, and turns what it finds into actions a person approves.
One deployment, end to end
What runs for a 78-store QSR group today, from the systems it reads to the people who use it.
Nine systems
- Tillsevery morning
- Stock systemnightly copy
- Accounting and distributionread only
- Payrollnightly
- Two delivery platformsweekly
- Finance mailboxes and drivesby sender
- Reviews and safety auditsdaily
Every night, unattended
- Each source against anotheror a count
- Journals against the booksline by line
- Our stock engine against the vendor'severy store
- Every job proves it ranor it is flagged
The right view for each role
- Operations portalleadership, finance, regions
- Store appevery store
- Assistantweb and chat apps
- Morning emailbefore the first meeting
One client, a 78-store QSR group in South Africa. Scroll.
The accounting system, rebuilt and checked
- Problem
- Finance keyed journals into the accounting system by hand, from till reports, landlord invoices and payroll runs, and no month could be checked line by line without starting again.
- Built
- A double-entry ledger of our own, loaded with six years of the group's history and balanced month by month. Journals for sales, rent, delivery, payroll, royalties and amortisation are built straight from the source systems. A cash book learns how each bank line was booked before, a payment trail follows every supplier payment to the bank, and supplier bills are captured in the portal and approved by a second person.
- Result
- Every automatic journal is checked line by line against the books before anyone relies on it, and any gap is named.
The store app
- Problem
- Counts, deliveries and waste were recorded on paper and in a vendor's system, typed up later, with errors found weeks after they mattered.
- Built
- A store app on the store's tablet: counts grouped the way the stock room is laid out, deliveries, waste, made in store, the daily checklist and notices from head office. It installs from the browser and keeps working when the connection drops.
- Result
- A count that looks wrong asks for a recount before it can be submitted, and every entry lands in the stock engine the same day.
A stock engine of our own
- Problem
- Stock figures came from one vendor's system, with nothing to check them against and no way to leave.
- Built
- A stock engine on a nightly copy of the vendor's database: the same counts and recipes, our own calculations, and one place to edit items, recipes and reasons.
- Result
- Every night its figures are checked against the vendor's, store by store and item by item, so the switch happens on evidence.
Audits, visits and corrective actions
- Problem
- Audit reports, visit forms and health and safety findings sat in inboxes, folders and outside portals, so nobody could see which stores were overdue or which findings were still open.
- Built
- Every morning the portal reads the auditors' food safety, brand standards and health and safety reports, the district manager and quality visit forms, and a quarterly health and safety checklist. Every audit with findings opens a corrective action: the store explains what happened and what it did, the district manager verifies, quality assurance closes.
- Result
- 86 health and safety audits with 972 findings, 230 food safety and brand standards audits and 294 store visits in one view from the first runs, with overdue visits and expiring certificates flagged.
Third-party aggregators reconciled
- Problem
- Two third-party aggregators sent weekly report exports. Nobody could say, per order, what was late, missed or misreported, or whether the payout matched the sales the aggregator claimed.
- Built
- An ingestion pipeline that collects the exports each week, validates they are complete, hashes and stages them, and loads order-level data into a portal on Google Cloud. Reconciliation compares aggregator-reported sales to payouts and flags the gaps in rand.
- Result
- Order-level visibility for every store every week, and a recoverable number for under-reported payouts.
Ask the business
- Problem
- Store sales sat in the POS system behind reports nobody had time to run. Simple questions like yesterday's sales at one store took a day to answer.
- Built
- An assistant connected to the portal, with about 128 tools across sales, stock, labour, property and finance. The operations team asks in plain English, and every answer stays inside the asker's access and names the records it came from.
- Result
- Same-day answers across the business, with no new reports to maintain.
Loss prevention and labour
- Problem
- Voids, discounts and corrections were buried in till reports, and labour was planned in a spreadsheet nobody could check against the hours worked.
- Built
- A loss-prevention view: corrections and voids by named operator, valued, with wastage outliers, sales-integrity flags and a watchlist by region. Schedules are built to the group's labour standard, which the engine reproduces exactly, and compared with timecards.
- Result
- Till-side loss is as visible as stock loss, and every schedule is measured against the hours actually worked.
Leases and turnover rent
- Problem
- Lease terms lived in signed PDFs, and turnover rent was checked by hand, if at all.
- Built
- A lease register with expiries, renewal windows and guarantees. Each week the portal reads the signed leases and proposes the turnover-rent terms, quoting the clause, and a named person accepts them. Rent billed is then checked against rent due from actual sales.
- Result
- Every landlord invoice is checked before it is paid, and nothing read from a lease becomes a figure until a person accepts it.
Repairs and maintenance ticketing
- Problem
- A 78-store QSR group had no way to centralise the logging of repairs and maintenance across its stores. Nobody could see in one place what was open, who was fixing it, or what it had cost.
- Built
- An installable web app with two screens. Store staff pick the store, category and priority, describe the fault and attach a photo or video. The maintenance team triages, assigns a vendor, logs the cost and moves the ticket from open to fixed, with the store signing off before it closes. Sign-in works on any email address, and every change lands in an activity log.
- Result
- One ticket log for 46 stores, 56 vendors and 250 users.
Six things
we own.
Built for ourselves or for a partner, IP held by aistrategy.agency. Each one is the governance model applied to a different kind of consequence: an organisation's data, mail, money, other agents, people's time, and permission to test someone else's systems.
Vernier
Our operations intelligence engine. It connects the data an organisation already has, checks each source against the others, and turns what it finds into actions a person approves: a morning briefing, an exceptions list with a cost and an owner against each gap, and an assistant that answers with every figure linked to its source. The nine systems above are parts of it, running in production.
- Any source with an export or API
- Google Cloud or AWS
- Access by role, overrides logged
- Running in production
Azani
A personal assistant that reads a consolidated mailbox, sorts what needs a reply, drafts each one in the owner's voice, researches with sources and captures notes into tasks and Drive. Sends nothing without a tap. Live at azani.aistrategy.agency for its owner; the homepage demo is a stripped-down version.
- Nothing sends without a tap
- Passkeys
- Swappable model
- Web and Android
PocketAlpha
A trading planner and paper-trading workspace, built to prove how far the same governance model goes when money is involved. Mandatory stops and targets, a daily loss lock, quotes that expire, an append-only ledger, idempotent fills. Live exchange plumbing behind a hard per-order cap and a typed confirmation, with a shadow-mode signal that logs what it would have done before it may act.
- Shadow mode first
- Owner-only sign-in
- Not a broker, not advice
Echelon
A small team of AI agents instead of one generalist. Marshal orchestrates; Herald finds, Minerva analyses, Mason builds, Penn drafts, Sterling checks. No two overlap. When a check fails, the work goes back to whoever produced it with specifics until it passes, and every action lands in a per-agent log the orchestrator reads across.
- Six agents, tested on real tasks
- Same boundary rule in every agent
- The delivery engine behind client work
TimeTraders
A local service exchange where people trade hours, not money. One timestamp is one hour, credited in quarter-hours, and a service costs exactly its duration. Every new member gets one timestamp, locked until they have listed a service and been vouched for by someone real. NGOs will confirm volunteer hours the same way, with a person on each side of every credit. In development at timetraders.app: the public pages, sign-in, listings and the wallet rules are live; the booking ledger and payments are not yet.
- One hour, one timestamp
- Every credit vouched for
- Append-only audit events
- No payments yet
iDatasec In development
Managed security testing with a person behind it. It finds what an organisation exposes to the internet, checks it for known weaknesses, and turns the results into a short fix list that a named consultant reviews before the client sees it. Nothing is tested until the client has proved they own the domain and signed an authorisation for each target. The first step is a free Exposure Snapshot, built from public sources only. A consultant-run pilot comes first.
- Permission first, per target
- Every finding reviewed by a person
- Passwords never stored
In their words.
Running more than 40 locations, our problem was never whether the technology could do it. It was operational creep and data that didn't join up. We didn't get a demo or a deck. We got automated reconciliations that work with the systems we already had, and an audit trail we can follow. Branch managers get a useful summary every morning. Anything with money attached still waits for a person to approve it. It took hundreds of hours of dull work off our people without adding risk we couldn't see.
Chief Operating OfficerRegional quick-service restaurant and retail group
In lending and wealth management, an AI that makes something up and sends it to a client is not a mistake we can absorb. What won our audit committee over was the boundary control. Their line is that consequences need a person, and the build follows it. The system does the slow work of reading portfolio data and drafting client briefs. An advisor still decides whether anything goes out. It's POPIA-aligned, it runs in our own cloud, and the board stopped asking me about it, which was the outcome I wanted.
Chief Risk and Compliance OfficerFinancial services firm
Most of the agencies we spoke to wanted to sell us a platform and keep us on it. This was the opposite. The architecture is vendor-neutral and it runs on our own infrastructure. They went through our fulfilment handoffs, took out the duplicate manual entries between dispatch hubs, and left us with an audit trail from one end to the other. If a better model comes out next month, we can swap it in without rewriting anything. Not many people in this market build that way.
Chief Technology OfficerRegional logistics and distribution network
Running clinics across several disciplines means a constant drag of administration: intake triage, referral paperwork, balancing schedules. We couldn't have a system inventing patient notes, and we couldn't have questions about where the data sits. They worked out which of those bottlenecks were actually worth automating and left anything clinical alone. Our admin staff get back more than 15 hours a week, and it's documented well enough that my own team runs it.
Managing DirectorIntegrated healthcare network
We'd had a run of AI pilots that went nowhere and cost real money. The difference here was that the roadmap was tied to numbers I recognise, unit economics rather than whatever the industry was excited about that quarter. Research and drafting were split into defined roles, with a check before anything gets relied on. We went from experimenting with prompts to running something we can depend on.
Managing PartnerCommercial law and corporate advisory practice