Work
Client work is anonymised. Each case says what was wrong, what we built, and what changed. Then the four products we own.
One client, a 78-store QSR group in South Africa. Scroll.
Delivery platform reconciliation
- Problem
- Two delivery platforms sent weekly report exports. Nobody could say, per order, what was late, missed or misreported, or whether the payout matched the sales the platform 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 platform-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.
Point of sale you can question
- 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
- A connector between the POS reporting layer and an AI assistant, so the operations team asks in plain English and gets figures traced to the underlying revenue centres. Deployed in the client's own Google Cloud project.
- Result
- Same-day answers on sales, ticket counts and item movement, with no new reports to maintain.
Repairs and maintenance ticketing, off per-seat licensing
- Problem
- The existing no-code ticket app charged per user and could not license staff on outside email domains. The business wanted 250 users; the licence model made that impossible.
- Built
- A rebuild as an installable web app: one screen for store staff to report a fault with a photo, one for the maintenance team to triage, assign vendors and log cost. Email-link login works across any domain. Submissions queue offline and send when signal returns.
- Result
- No seat fees, no app store, 46 stores and 56 vendors on one system.
Stock counts on phones
- Problem
- Weekly stock counts ran on paper and spreadsheets, with store and region typed by hand and errors found weeks later.
- Built
- Mobile count forms where choosing a region reveals only that region's stores, with the count grouped by category and feeding the inventory system directly.
- Result
- Counts arrive complete and correctly attributed, ready to reconcile.
Four 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: mail, patients, money, and other agents.
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.
- Google Cloud, Johannesburg
- Passkeys
- Swappable model, no stored API key
- Web, PWA, native Android
MedSync
A multi-tenant treatment management platform for clinics: patients, protocols, sessions, appointments, beds, staff, labs, vitals and notes, with analytics on top. Several organisations run on one platform without seeing each other's data, and every record carries an activity log for the question an auditor asks a year later.
- Four-level access model
- React, Node, Prisma, PostgreSQL
- Azure or Google Cloud
- Built for a managed services partner
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.
- Firebase, Firestore, Cloud Functions
- 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