16 builds,
and the story behind each.

The challenge

South African doctors lose hours every day to paperwork, and automating it is a high-stakes problem: a clinical note has legal weight, a consultation recording is about as private as data gets, and a doctor will abandon the product the first time it loses their work. The system had to feel instant and still meet the standard a medical record demands.

How we built it

We built the platform end to end around an AI scribe that drafts the paperwork while the consultation happens, with a second safety path running behind it so nothing is lost if the connection drops mid-appointment. Doctors review and confirm instead of writing from scratch, and once a note is signed it can never be silently changed, there is always a faithful record of what was generated and what the doctor corrected. Privacy is built into the foundations rather than the settings page: patient data is encrypted, nothing records without the patient's consent captured first, and the whole platform follows the international health-data standards hospitals use, which is what let us connect legally-recognised electronic prescriptions without rebuilding anything.

• One recording becomes five finished documents, ready to review
• The scribe keeps working even when the connection does not
• A signed note can never be silently altered afterwards
• Nothing is recorded without the patient's consent captured first
• Telehealth in the browser, no app for the patient to install
• Built on international health-data standards, so it connects to the wider system

What we learned

Doctors only trust automation they can check. Making the review step feel like a quick confirm, with every generated line one tap from an edit, did more for adoption than any accuracy figure, and the safety promises had to live in the foundations of the system, where no bug or shortcut can undo them.

The challenge

Autoyard's promise is a private auction: verified dealers bid on a car that is never listed publicly, and the seller's identity stays hidden until they accept a bid. That anonymity is a contractual promise, not a feature. The platform also has to serve three very different audiences at once, sellers, dealers and the operations team, each with their own way in and their own view of the same deal.

How we built it

The platform is really three products sharing one engine, and each audience gets an experience shaped for them: sellers sign in with a code to their phone, dealers work from a vetted partner portal, and operations runs the whole market from an internal console. The promise that holds it together is anonymity, so we built the system in a way that dealer screens simply have no path to a seller's identity, it is not hidden by good behaviour, it cannot be fetched. A seller's registration number pulls the full vehicle spec in about thirty seconds, listings reach matched dealers with identifying details masked, offers land together in a timed auction, and every deal moves through clearly defined stages from first bid to same-day settlement.

• A registration plate becomes a full vehicle spec in about thirty seconds
• Sellers stay anonymous until they choose to accept an offer
• Three products in one platform: sellers, dealers and operations
• Bids land together in a timed auction, no haggling
• Dealers are vetted before they see a single listing
• Every deal moves through clear stages, nothing gets stuck in between

What we learned

Promises you build into the foundations survive every future change; promises kept by good intentions survive until the next deadline. Seller anonymity went into the foundations on day one, and it has held through every version of the platform since.

The challenge

Goshen Farms raises heritage poultry, livestock and indigenous crops, and almost everything about the operation changes with the seasons: what is available, what is on pre-order, which breeds are being showcased. A conventional site would be stale within a month. The real problem was giving a farming family full control of their own content, without a developer in the loop and without edits ever breaking the design.

How we built it

We built the site around a content system shaped like the farm itself: breeds, produce, seasonal campaigns, stories and wholesale offers each have their own editable structure, and the editing tools live inside the site, so there is no second system to learn. The design draws from that structure, which means the family can change anything the content allows and nothing that would break the layout. Farm photography is automatically resized and compressed so it loads quickly even on rural connections. For ordering we deliberately built less, not more: no cart, no checkout, just a structured WhatsApp order, because that is where the farm's customers already are. Retail buyers and wholesale buyers are served from the same catalogue through different flows.

• The family updates produce, breeds and campaigns themselves
• Editing happens inside the site, no separate system to learn
• Edits can restyle the content but never break the design
• Farm photography tuned to load fast on rural connections
• WhatsApp ordering instead of a checkout, where the customers already are
• Retail and wholesale served from the same product catalogue

What we learned

For a small producer, the content system is the product. Time spent making it match how the family actually thinks about their farm did more for the site's longevity than any feature, and removing the checkout was the single best sales decision on the build.

The challenge

Taking a real pharmacy online is not a brochure problem. If the stock count drifts, a customer arrives at the counter for medicine that is not there. If a payment is mishandled, real money moves wrongly. And a prescription is among the most sensitive documents a customer will ever upload. The quality bar is set by what must never go wrong, not by what usually goes right.

How we built it

We built the store on foundations where the dangerous mistakes are impossible rather than unlikely: stock and orders always change together, so the shop can never sell what the shelf does not have, and every payment is independently verified before it can touch an order, so a glitch or a double-click cannot move money twice. Prescriptions are compressed on the customer's phone and uploaded privately, visible only to the pharmacy team. Delivery is limited automatically to the pharmacy's real delivery area, and the staff run the whole operation, products, orders, prescriptions, specials, from their own admin side of the same platform. Customers shop by health concern, the way people actually ask at the counter.

• Stock and orders always move together, so overselling cannot happen
• Payments are independently verified before they touch an order
• Prescriptions upload privately, visible only to the pharmacy team
• Delivery is automatically limited to the pharmacy's real delivery area
• Staff manage products, orders and prescriptions from their own admin side
• Shop by health concern, the way customers actually ask at the counter

What we learned

Online shops fail at the edges, the double-click, the connection that drops mid-payment, the two customers buying the last item at once. Getting the money and stock handling correct under all of those first is why this store runs quietly, and it is where we now start every commerce build.

The challenge

Solar installation is a search-driven purchase in a crowded market: whoever shows up for the town and answers the cost question first gets the enquiry. Simply Solar needed to compete with bigger installers on visibility without a marketing team, and the site had to stay fast on the rural connections much of their audience browses from.

How we built it

We built the site to be extremely fast and extremely findable. Every town and service area gets its own dedicated page, each properly set up for local search, so the site meets customers exactly where they are searching. All content lives as structured data rather than in a heavy management system, which keeps the site loading instantly and means adding a new town or article is a quick edit, not a project. The one genuinely interactive piece is a savings calculator that turns the vague 'what would solar actually save me?' into a concrete number, and a concrete number into an enquiry. The site is also prepared for how people search now, readable by the AI assistants that increasingly answer questions before Google does.

• A dedicated page for every town and area they serve
• An interactive savings calculator that turns curiosity into enquiries
• Adding a town or an article is an edit, not a development project
• Loads instantly, even on rural connections
• Built to be found by search engines and AI assistants alike
• Every enquiry routes to WhatsApp, where the conversation actually happens

What we learned

One well-aimed interactive tool converts better than any amount of persuasive copy, and for local trades, a fast plain site that shows up in the right town beats a beautiful one that does not.

The challenge

Trading is the harshest test environment for AI engineering we could pick: the data is noisy, the feedback is brutal, and a confidently wrong model costs real money. We built Agentic Signals to answer a question clients ask us constantly, how do you use AI in a domain where sounding right and being right are not the same thing?

How we built it

The answer is a system where the AI is surrounded by checkpoints it cannot talk its way past. Before the AI is consulted at all, the system checks that the market data is trustworthy and that conditions are even worth analysing, most of the time the answer is no, and no signal is the correct output. When the AI does weigh in, its suggestion is double-checked against the raw market data, then passed through hard risk rules, how much can be at stake, whether the potential reward justifies it, that are enforced by plain code the AI cannot override. No signal leaves the system on the model's word alone. Afterwards, the system records what actually happened to every call it made and reviews its own track record weekly, so it learns from results, not just opinions.

• Market conditions are checked before the AI is ever consulted
• Every AI suggestion is double-checked against the raw market data
• Hard risk rules that no signal can bypass, enforced by code, not the AI
• The system records what actually happened after every call it makes
• It reviews its own track record and reports on itself weekly
• Bad or missing market data is caught before it can cause a bad signal

What we learned

The AI never gets the last word. Everything that makes this system trustworthy is the ordinary, careful engineering around the model, the checks before, the rules after, the honest scorecard, and that pattern now shapes every AI project we take on for clients.

The challenge

The core promise is a single number: what you need on the next assessment to reach your target grade. That number has to be exactly right across three curricula, CAPS, IEB and Cambridge, each with its own weighting rules, because a student who catches the calculator being wrong once will never trust it again.

How we built it

We built the calculation engine as its own carefully tested component, one model per curriculum with the marking rules written out explicitly, kept separate from the rest of the app so it can be verified on its own and trusted everywhere it is used. The calculator itself is free and open, no account required, a deliberate decision: trust is earned before signup, and accounts exist only for the things that genuinely need remembering, tracked marks, study streaks, progress over a school career. Behind the accounts sits a rich structure connecting journeys, terms, subjects, assessments and mark history, so as results come in, the target number updates with them.

• Handles the different marking rules of CAPS, IEB and Cambridge
• The calculator is free and open, no account needed to use it
• Every mark and assessment tracked, so the target updates as terms unfold
• The calculation engine is tested in isolation, so the number is dependable
• Study streaks and progress designed to reduce exam anxiety, not add to it
• From Grade 10 to university, one companion across the journey

What we learned

Put the maths where you can test it. Keeping the calculation engine separate from the screens and the database is what made three-curriculum accuracy achievable, and making the core tool free with no signup wall is what earned the audience.

The challenge

A pharmacy delivery service is really three products that must agree with each other at all times: a customer app placing orders, a driver app fulfilling them, and a pharmacy dashboard dispatching them. Build them separately and you maintain three apps that slowly drift apart. Build them together carelessly and you get one app that does nothing well, all of it running on mobile networks that come and go.

How we built it

We built all three apps from a single codebase, sharing one foundation while each role gets a focused experience. The heart of the system is the order itself: it moves through clear stages, placed, dispatched, picked up, delivered, and every role sees the same order at the same moment, with push notifications firing at each handoff. Because delivery work happens on unreliable connections, the apps are built to keep working through dropouts and catch up the moment signal returns, rather than losing anything. Chronic medication and repeat prescriptions are first-class features, not afterthoughts, and monitoring was wired in from the first build so problems surface to us before they surface in reviews.

• Customer, driver and pharmacy apps built as one product, not three
• An order moves between all three roles in real time
• Keeps working through the network dropouts delivery runs on
• Push notifications keep everyone informed at every handoff
• Chronic medication and repeat prescriptions built in
• Problems are monitored from day one, not discovered from reviews

What we learned

A multi-sided service lives or dies on the operations side, if dispatching is not effortless for the pharmacy, the smooth customer experience never happens. Treating the order as one shared source of truth that every role watches, rather than three apps messaging each other, is what kept the system dependable as it grew.

The challenge

An invoice is a legal document. SARS prescribes what it must contain, VAT has its own arithmetic, the required format changes above a set amount, and invoice numbers must run in sequence. PaidIt promises a small business their first compliant invoice in under a minute, which means the software has to carry the entire compliance burden, including the part where AI is helping write the invoice.

How we built it

Compliance lives in a set of tested rules that behave the same way every time: the VAT arithmetic, the automatic switch between invoice formats at the legal threshold, numbering that can never skip or repeat. The AI sits in front of those rules, not inside them. It turns a plain-language description of the job into draft line items, which is the part users love, but every amount on the final document is calculated by the rules, never taken from the AI's draft. Payments and invoices are recorded so they can never disagree with each other, finished documents are generated once and kept, and recurring invoices and payment reminders run on their own schedule without anyone remembering to send them.

• Describe the job in a sentence, the AI drafts the invoice
• Every amount is calculated by tested rules, never by the AI
• SARS requirements and VAT handled automatically, including format rules
• Invoice numbers can never skip or repeat
• An invoice and its payments can never disagree
• Recurring invoices and payment reminders run themselves

What we learned

AI in a legal document flow works when the AI proposes and the code decides. Users get the magic of describing an invoice in a sentence, and SARS never sees a number the rules did not compute. The channel insight held too: an invoice that gets opened gets paid, and WhatsApp gets opened.

The challenge

Project Master Thatching had twelve years of craft and more than five hundred completed roofs, but little online presence to match. The brief was trust at a glance: a site that carries the weight of that track record for a visitor who has never heard of them, works on a phone in the sun, and makes requesting a quote a one-tap action.

How we built it

We built the site image-first, because for a craft trade the gallery is the argument: a masonry grid of completed roofs optimised to load fast on mobile, backed by a four-step process timeline from first consult to final inspection that shows a visitor exactly what engaging them looks like. Coverage badges for eighteen-plus service areas do the local-search work, quote requests route through WhatsApp where the trade's customers already are, and the FAQ answers the two questions every prospect actually has, cost and fire safety, before they need to ask.

• Six service showcases with imagery
• 4-step process timeline (consult to inspect)
• Masonry project gallery of completed roofs
• 18+ service area coverage badges
• WhatsApp-integrated quote requests
• Detailed FAQ covering costs and fire safety

What we learned

For a craft trade, proof beats promises. Leading with real finished roofs and a concrete process did more to win trust than any amount of marketing copy, and cutting everything that stood between a convinced visitor and the WhatsApp button was the highest-value work on the build.

The challenge

AI that reads documents is easy to demo and hard to trust: totals that do not add up, failures that slip through quietly, and no idea what the processing cost until the bill arrives. We built this pipeline as an internal study of what it takes to do it properly, as if it processed a real finance team's inbox, where a wrong number is worse than no number.

How we built it

The system is built on one idea: never take the AI's word for anything you can check. Every extracted invoice is tested against itself, do the line items add up to the subtotal, does the arithmetic hold, do the dates make sense, and its confidence score comes from those checks, not from asking the AI how sure it feels. Anything that fails a check is flagged for human review rather than quietly accepted. Simple, clean documents are processed quickly and cheaply, while difficult ones automatically get more careful treatment, and the exact cost of processing every document is recorded, so there are no surprises at the end of the month. Every step keeps its own history, so any document's journey can be traced and any step re-run.

• Reads invoices from PDFs, photos and scans
• The system checks the maths itself, it never trusts the AI's word
• Anything uncertain is flagged for a person, not silently accepted
• Simple documents are processed cheaply, difficult ones get more attention
• The cost of processing every single document is tracked
• A full history of what was read, checked and corrected

What we learned

Never ask an AI how confident it is, measure it. Checking the maths caught the errors that mattered, and tracking cost per document changed how we designed the whole system. Both lessons now travel with us into every AI project.

The challenge

An HR system holds the most sensitive information a company keeps about its people, salaries, performance reviews, disciplinary records. PeopleBase serves many companies from one platform, so the one failure that can never happen is a single record from one company surfacing in another's account. Everything about how it was built flows from taking that seriously.

How we built it

Company separation is enforced at the deepest layer of the system, not in the screens: every piece of data belongs to a company from the moment it is created, and the platform itself refuses to serve it anywhere else. Within a company, access follows the org chart, employees see their own information, managers see their teams, HR sees the whole picture. Before go-live we ran a deliberate hardening pass, testing the platform the unforgiving way, with real accounts, real roles and real data rather than simulations, until we were satisfied the walls held under every scenario we could construct. Around the core sit the practical things a production system needs: heavy tasks running in the background so the app stays quick, protection against abuse, and the privacy rights South African law grants employees built in from the start.

• Every company's data is walled off at the deepest layer of the system
• Leave, performance, recruitment and org chart in one place
• Employees see their own view, managers see their team, HR sees it all
• Tested before launch with real accounts and real data, not simulations
• Privacy law (POPIA) rights built in, not bolted on
• Heavy work runs in the background, so the app stays fast

What we learned

Security you test with simulations is security you are taking on faith. The pre-launch pass with real accounts and real data caught what polite testing never would have, and it is now a standing step in how we ship anything that holds sensitive data.

The challenge

Digitising a clinic's patient journey means holding South African ID numbers and medical records, information that staff must be able to search in a heartbeat but that should never sit readable in a database. Those two needs pull hard against each other: protect an ID number properly and, done naively, you can no longer look a patient up by it. Solving that tension, without slowing the front desk down, was the heart of the build.

How we built it

We designed the system so that patient identity is protected and useful at the same time: ID numbers are never stored in plain text anywhere, yet reception can still find and match a patient instantly. On screen, personal details stay masked unless a staff member deliberately reveals them, and that reveal is itself recorded. Everything is on the record, every look at a file, every change, every medicine dispensed, so the clinic can always answer who saw what, when. Dispensing requires two staff members to verify a prescription, with automatic allergy checks, and stock adjusts the moment medicine leaves the shelf. Records follow the international health-data standards used across the industry, so the clinic's data stays portable rather than locked in.

• The full patient journey, from front desk to dispensary, in one system
• ID numbers are never stored in plain text, yet staff can still find a patient instantly
• Personal details are masked on screen unless deliberately revealed
• Every access, change and dispense is on the record
• Two staff members must verify a prescription before it is dispensed
• Built on international health-data standards, so records are never trapped

What we learned

Privacy done properly is invisible to the people doing their jobs, reception never notices that the ID numbers they search for are protected. And building the audit trail first, rather than bolting it on, quietly improved the design of every feature that came after it.

The challenge

The buildathon brief was AI over small-business finances, which is a trap: AI doing arithmetic on someone's VAT will eventually be confidently, expensively wrong. We set ourselves one hard rule before writing any code, no number produced by the AI would ever reach the ledger.

How we built it

The system is a strict division of labour: the AI reads, the code calculates, the AI explains, the human approves. The AI's only job is to read receipts, from pasted text, photos or voice notes, and to narrate what the numbers mean in plain language. Every actual calculation, the VAT arithmetic, spotting duplicates, flagging unusual amounts, deciding what is claimable, is done by thoroughly tested code that behaves the same way every time, and it overrides anything the AI wrote. When a receipt cannot be read properly, the system says exactly what is missing and asks, rather than inventing a value, and a batch with a few unreadable receipts still processes the rest instead of failing entirely. Nothing enters the ledger without a person approving it, and serious issues block approval until they are resolved.

• Receipts arrive as text, photos or voice notes
• The AI reads receipts, but every calculation is done by tested code
• When something cannot be read, it asks, it never guesses
• Duplicates and unusual amounts are flagged automatically
• Nothing enters the ledger without a person approving it
• Flags which VAT claims the paperwork will not actually support

What we learned

Discipline is what turns AI from a demo into a tool: check its output, let it retry once, then fail honestly and visibly. And partial results beat all-or-nothing, showing nine cleanly read receipts out of thirteen with the rest flagged earns far more trust than rejecting the whole batch.

The challenge

Can an AI run a real commercial brand, products, imagery, customer email, payments, without a human babysitting every step, and without hiding what it does? Most AI experiments fail on the second part. Our position is that an autonomous system needs accountability before it needs abilities, so we are building the accountability first.

How we built it

Mahiki runs on a simple loop with a leash. The AI proposes what the brand should do next; a human approves or vetoes it with a tap; only approved actions actually happen, payments, product imagery, emails to customers; and every decision is then published to a public log alongside the AI's own reasoning, so anyone, including the brand's customers, can read why it did what it did. Nothing involving money or people moves without sign-off. Deliberately, we designed the entire system on paper before writing code, what the AI may do, what it may never do, what gets recorded, because in an autonomous system the rules are the product, and the features are just what the rules permit.

• The AI proposes, a human approves, and only then does anything happen
• Every decision the AI makes is published openly, with its reasoning
• Nothing involving money or customers moves without human sign-off
• The AI works with real tools: payments, imagery, customer email
• Designed on paper first, because the rules matter more than the features
• Built to South African privacy law from the first line

What we learned

Still in the building, but the design phase settled one thing: openness cannot be added to an AI system later. Publishing every decision changes how you design everything else, and starting from that constraint, rather than retrofitting it, is the whole experiment.

The challenge

Voice AI lives or dies on the pauses. Do the listening, then the thinking, then the speaking one after another and the silences between turns kill the illusion of conversation. We wanted real conversation speed on an ordinary laptop, no server farm, plus a personality distinct enough to feel like company rather than a command line.

How we built it

The trick is overlap. Instead of waiting for the AI to finish its whole reply, the system watches the reply as it forms, and the moment the first sentence is complete, it starts saying it aloud while the rest is still being written. The pauses collapse, and the conversation starts to feel alive. Listening happens on the device itself, so voice audio never leaves the machine. We measured obsessively, every step of every reply is timed, from the moment you stop talking to the moment it starts answering, with the numbers on a live dashboard beside an animated face that shows what it is hearing and thinking. And when the connection to the AI fails, it apologises in character and recovers, rather than going silent.

• Starts speaking the moment its first sentence is ready
• Listening happens on the device itself, voice audio goes nowhere
• Every step of every reply is timed, so slowness has nowhere to hide
• A live animated face shows what it is hearing and thinking
• When the connection fails, it recovers in character instead of going silent
• A distinctly South African personality, by design

What we learned

Speak by the sentence, not by the reply, that one decision is most of the magic. And what you measure is what you improve: the moment response time became a number we watched on every turn, it became the thing the whole system was tuned around.