What the work actually changes
A sample of recent engagements. Each states the situation, what was built and what changed as a result. Names appear only with the client's explicit consent, and any figure shown says how it was arrived at.
Filter by capability
The Friday stock reconciliation stopped happening
- Client
- A supermarket group with branches across several county towns
- Location
- Kenya
- Capability
- Systems integration and automation
- Stock shrinkage against turnover
- 2.4% to 1.4%
- Measured during the engagement, first quarter after go-live
- Staff hours returned each week
- 18 hours
- Measured during the engagement, measured over eight weeks
The situation
Each branch ran its own till and counted its own stock, and head office learned the group position at the end of the week, by which point it described a week that had already been traded. Transfers between branches were recorded twice or not at all. Buyers ordered against a picture that was several days old, so fast lines ran out while slow lines sat in the back.
What we built
We put one inventory registry behind every branch, so a sale, a receipt or a transfer writes to the same record wherever it happens. Branch tills post as they trade rather than at close. Transfers became a single movement with two confirmations instead of two independent entries, which is what had been producing the phantom stock. Reorder points are now calculated from recorded movement per branch rather than from a buyer recalling what went last month.
What changed
- The weekly reconciliation between branch counts and head office no longer exists as a task
- Group stock position is current rather than as at last Friday
- Transfers reconcile automatically, so stock stopped disappearing between branches
- Reorder points are calculated from recorded movement, per branch, per line
Every member record access became attributable
- Client
- A savings and credit co-operative society
- Location
- Kenya
- Capability
- Cybersecurity and digital trust
- Sector
- Financial Services
- Time to produce an access report for an examiner
- 3 days to 10 minutes
- Measured during the engagement, at the first audit after handover
- Accounts holding standing administrative rights
- 14 down to 2
- Measured during the engagement, at completion of the access review
The situation
Staff shared logins on the member system, so an entry could be traced to a desk but not to a person. Access had accumulated: people who had changed roles kept the permissions they arrived with, and nobody had removed a leaver. Preparing for an examination meant reconstructing who could have seen what, from memory.
What we built
We gave every member of staff their own credential, enforced multi-factor authentication, and rebuilt permissions around role rather than around history. A joiner-mover-leaver process now grants and removes access as a matter of routine instead of on request. Access to member records is logged immutably, and the log is exportable in the form an examiner asks for.
What changed
- Shared logins were removed; every action on a member record names a person
- Permissions follow the role, and change when the role changes
- Leavers lose access on their last day rather than eventually
- The access report an examiner asks for is produced on demand, not reconstructed
A platform decision made on evidence rather than on a demonstration
- Client
- An asset and wealth management firm
- Location
- Nairobi
- Capability
- Technology strategy and architecture
- Sector
- Financial Services
- Saved against the leading vendor quote
- KES 2.4M
- Measured during the engagement, against the shortlisted proposal
- Implementation months avoided
- 5 months
- Measured during the engagement, against the original plan
The situation
The firm was being quoted for a new portfolio and client-reporting platform by several vendors, each demonstrating against its own strengths and none against the firm’s actual reporting obligations. The internal debate had become a matter of preference, because there was no shared statement of what the system had to do.
What we built
We wrote the requirement first: the reports that must be produced, the data each needs, the controls the regulator expects, and what the firm already holds that any new platform must accept. Vendors were then evaluated against that document rather than against their own scripts, including on migration cost and exit cost, which neither quote had addressed. We took no commission from any vendor and had no interest in which one won.
What changed
- A written requirement exists, so the decision can be explained to a board
- Vendors were compared on the same criteria, including cost of leaving
- Migration effort was estimated before commitment rather than discovered after
- The firm owns the requirement document and can reuse it at renewal
Term start stopped being the day the platform fell over
- Client
- An online school serving learners across several African countries
- Location
- Regional, Africa
- Capability
- Cloud and infrastructure
- Enrolment-week availability
- 99.9%
- Measured during the engagement, across the first two enrolment weeks
- Enrolments completed without a support call
- 94%
- Measured during the engagement, first term after launch
The situation
Demand was concentrated: quiet for most of the term, then every learner and parent arriving within the same few days at enrolment and at results. The platform was sized for the average and therefore failed at the peak, which was precisely when a family was deciding whether to trust it. Learners on slow connections in smaller towns fared worst.
What we built
We separated the parts that must scale from the parts that do not, so a surge in enrolment no longer competes with routine teaching traffic. Static and media content moved to a delivery layer close to learners, and the pages were rebuilt to be usable on a low-bandwidth connection and a mid-range phone. Capacity is now planned around the peak week rather than the average one, and load is tested before term rather than discovered during it.
What changed
- Enrolment traffic no longer degrades the platform for learners already studying
- Pages are usable on a slow connection and a mid-range handset
- Peak capacity is tested ahead of term rather than discovered at term start
- Failures are alerted on rather than reported by parents
Donor reporting stopped being a month of retyping
- Client
- An international NGO operating between the United States and Kenya
- Location
- United States and Kenya
- Capability
- Data and applied AI
- Reporting cycle, previously
- 3 weeks, now 2 days
- Measured during the engagement, across two reporting rounds
- Staff days returned per reporting round
- 11 days
- Measured during the engagement, across two reporting rounds
The situation
Field teams recorded programme activity on paper and in spreadsheets, in formats that had grown up separately per programme. Every donor report meant collecting those files, reconciling categories that did not match, and rebuilding the same numbers by hand. Two reports covering the same period could disagree, and nobody could say quickly which was right.
What we built
We agreed one set of definitions across programmes, so a beneficiary, an activity and a period mean the same thing everywhere, then built the reporting layer on top of them. Field capture was standardised into forms that work offline and sync when a connection returns. Donor report formats are generated from the same underlying figures, so two reports covering one period cannot disagree.
What changed
- One agreed definition per measure, applied across every programme
- Field data is captured once, offline, and syncs rather than being retyped
- Donor reports are generated from the source figures, not rebuilt by hand
- Two reports covering the same period reconcile by construction
Feed, weight and sales records that survive a power cut
- Client
- A commercial pig farm
- Location
- Western Kenya
- Capability
- Managed services and support
- Sector
- Industrials & Agribusiness
- Feed cost per kilogram of gain, now measured
- 9% reduction
- Measured during the engagement, first full production cycle
- Records reaching the office same day
- 100%, from roughly half
- Measured during the engagement, first full production cycle
The situation
Production records lived in a notebook at the pens and were entered into a spreadsheet in the office when somebody had time, which meant days of drift and a costing that was always an estimate. Power and connectivity were both intermittent, so anything that assumed a live connection had already been tried and abandoned.
What we built
Capture moved to the pens, on a device that holds entries when the connection drops and reconciles them when it returns. Feed, weights, mortality and sales are recorded once, where they happen. On the infrastructure side we dealt with the parts that actually fail on a rural site: power protection, a fallback connection, and a backup that has been restored rather than assumed. It is now a monthly retainer, so somebody answers when it breaks.
What changed
- Records are entered once, at the pens, rather than twice with a delay
- The system keeps working through a power cut and a lost connection
- Feed conversion and cost per animal are calculated from recorded data
- Backups are verified monthly, with a restore actually tested
Tender conditions found in minutes, with the clause attached
- Client
- An engineering consultancy
- Location
- Nairobi
- Capability
- Data and applied AI
- Sector
- Professional Services
- Time to locate a precedent clause
- 40 minutes to under 2
- Measured during the engagement, measured across 30 queries
- Bid team hours per submission
- 31% reduction
- Measured during the engagement, across six submissions
The situation
Bid teams worked through long tender documents and technical specifications by reading them, and the knowledge of what a previous similar tender had required lived with whoever had worked on it. A question about precedent meant finding the right person, and if that person was on site it waited.
What we built
We deployed retrieval across the practice’s own archive of tenders, specifications and past submissions. A question in plain language returns the relevant passage together with the document and clause it came from, so an engineer verifies rather than trusts. Everything runs inside a tenant the practice controls, with retention set by the practice and the archive excluded from third-party model training by configuration and by contract.
What changed
- Precedent is searchable by anyone on the bid team, not only by whoever wrote it
- Every answer arrives with the document and clause behind it
- The archive stays in a tenant the practice controls
- Nothing from the archive is used to train a third-party model
Wholesale orders stopped living in a WhatsApp thread
- Client
- A bakery supplying its own shop and wholesale accounts
- Location
- Kenya
- Capability
- Systems integration and automation
- Wholesale orders short-delivered per week
- 6 down to 0
- Measured during the engagement, first month after go-live
- Time from delivery to invoice
- Same day, from 6
- Measured during the engagement, first month after go-live
The situation
Wholesale customers ordered by message, each thread its own record, and the production plan was assembled by scrolling through them the night before. An order missed in the scroll was a customer served short the next morning. Invoicing happened later, from the same threads, which is a poor place to keep an account.
What we built
Orders now arrive into one register whatever channel they come through, with per-customer pricing applied automatically rather than remembered. The production requirement is totalled from confirmed orders instead of assembled by reading. Delivery confirmation raises the invoice against the account, so billing follows what was delivered rather than what was ordered.
What changed
- Every wholesale order lands in one register, whatever channel it arrived on
- The production total is calculated from confirmed orders, not read off a thread
- Customer pricing is applied by the system rather than recalled
- Invoices follow delivered goods, raised the same day
Giving records and member data that a volunteer can run safely
- Client
- A religious institution with a single congregation
- Location
- Nairobi
- Capability
- Managed services and support
- Volunteer handover time
- 2 weeks to 1 day
- Measured during the engagement, at the first handover after migration
- Records recoverable after a device is lost
- 100%, from none
- Measured during the engagement, verified by restore test
The situation
Membership and giving records were held in spreadsheets on a volunteer’s personal laptop, with copies circulating by email whenever somebody needed a figure. When a volunteer moved on, the current version left with them. Nobody intended a data protection problem, but the institution held sensitive personal information and had no control over where it sat.
What we built
Records moved onto managed accounts belonging to the institution rather than to individuals, with access by role so a treasurer sees giving and a secretary does not. Backups run and are verified. We wrote the handover documentation for volunteers, because the real risk was never a technical one: it was that the person who knew how it worked would leave.
What changed
- The institution owns the accounts and the data, not a volunteer
- Access is by role, so sensitive giving data is seen only where it is needed
- A volunteer leaving no longer takes the current version with them
- Written procedure exists, so the next volunteer can be handed the work
One directory and one set of accounts across every congregation
- Client
- A religious institution with congregations across a region
- Location
- Regional, Kenya
- Capability
- Cloud and infrastructure
- Congregations on one directory
- All 9
- Measured during the engagement, at completion of migration
- Time to produce a regional return
- 2 days to 20 minutes
- Measured during the engagement, first return after migration
The situation
Each congregation ran its own arrangements: different email providers, records kept locally, and no way to reach the whole body without assembling addresses by hand. Central administration had no reliable count of anything, and every request for regional information began with a round of phone calls.
What we built
We consolidated onto one managed environment under the institution’s own domain, so every congregation has an account that belongs to the institution rather than to a personal address. Shared records sit in one place with per-congregation permissions. Where a congregation had a working local arrangement we left it and connected it, because replacing something that works is spending money to arrive where you started.
What changed
- One domain and one directory across congregations
- Regional information is reported from records rather than gathered by phone
- Accounts belong to the institution, so a departure does not take an inbox with it
- Congregations keep local autonomy where it was already working
An independent second opinion before committing the capital
- Client
- A managing partner at a professional services firm
- Location
- Nairobi
- Capability
- Technology strategy and architecture
- Sector
- Professional Services
- Saved against the original proposal
- KES 3.1M
- Measured during the engagement, against the proposal as first presented
- Contract terms renegotiated before signature
- 7 terms
- Measured during the engagement, before signature
The situation
The firm was preparing a significant software commitment. The partner had proposals in front of him, each internally coherent, and no way to judge them that did not depend on the people selling. The internal advocate for each option was also the person who would run it, which is not a criticism of anyone but does make an independent read valuable.
What we built
A fractional advisory arrangement: a fortnightly session with the leadership team, and a standing brief to say plainly when the answer was to do less. We reviewed the proposals against what the firm actually needed, examined the contracts including renewal and exit terms, and set the sequence of what should change first. We take no vendor commission, so there was no option we benefited from him choosing.
What changed
- Proposals assessed against the firm’s requirements rather than vendor scripts
- Contract terms, including renewal and exit, reviewed before signature
- A sequenced plan, so changes happen in an order that does not create rework
- A standing independent read at leadership level, fortnightly
A storefront that takes the money and tells the warehouse
- Client
- An online retailer shipping nationally
- Location
- Kenya
- Online orders completed without staff intervention
- 88%
- Measured during the engagement, first quarter after launch
- Gross margin on online orders
- +6.4 points
- Reported by the client, first quarter after launch
- Checkout abandonment
- 71% to 58%
- Measured during the engagement, first quarter after launch
- Availability through the launch campaign
- 100%
- Measured during the engagement, across the launch campaign
The situation
Selling online meant a social media page, a phone number and a person answering both. Orders were negotiated in messages, payment was confirmed by screenshot, and stock was whatever somebody remembered was in the store room. Every order took a conversation, which capped the business at the number of conversations one person could hold in a day. There was no site, so there was also nothing a returning customer could come back to.
What we built
We built the storefront, then everything underneath it. The catalogue draws from one stock record, so a line that is out cannot be ordered. Checkout takes mobile money and card, and a confirmed payment raises the order, notifies the packing bench and sends the customer a reference without anyone touching it. On the infrastructure side: hosting sized for a campaign spike rather than a quiet Tuesday, a certificate that renews itself, daily backups with a restore that has been tested, and the payment integration configured so card data never touches our client. It now runs on a retainer, so somebody is watching it and somebody answers when it breaks.
What changed
- Orders are placed and paid without a conversation, so volume is no longer capped by staff availability
- The catalogue cannot sell what the stock record says is gone
- Payment confirmation raises the order and notifies packing automatically
- Traffic spikes during a campaign are absorbed rather than survived
- Backups are verified and the restore has been rehearsed
- The site is monitored, patched and supported under a monthly agreement
Recognise any of these?
Most of the problems above looked unremarkable from the inside, and expensive once measured. A diagnostic is a fixed piece of work with a written output and no obligation to proceed.