Custom software development in South Africa

When off-the-shelf stops fitting

Most businesses run on a mix of packaged products, spreadsheets and integrations that grew one urgent request at a time. It works until it does not: the numbers in two systems disagree, a process lives in one person's head, and every change takes longer than the last because nobody is sure what it will break.

Custom software is worth building when the work is specific to how you operate, when it carries real weight (money, records, compliance, other people's customers), or when the connections between your existing systems have quietly become the system. It is not worth building when a product already does the job. We will tell you which side of that line you are on.

The cost that matters is not the first release. It is what the system costs to change in two years, when the person who built it may have moved on. That is the measure we build to.

What we build

• Operational platforms

  The internal systems a business runs on: case management, scheduling, approvals, records and the reporting on top of them. Workflow modelled on how your people actually work, not on a vendor's idea of it.

• Systems that handle money

  Payments, billing, wallets and reconciliation that balance to the cent and can still answer an auditor years later.

• Integration and legacy systems

  Connecting the systems you already have, including the old ones nobody wants to touch, through APIs we aim to keep documented and versioned. Sometimes the right move is to wrap a legacy system rather than replace it, and we will say so.

• Compliance designed in

  Consent, retention and the right to erasure built into the data model for POPIA, with European clients handled the same way under GDPR, and an audit trail on every privileged action.

• Customer-facing applications

  Portals and web applications your own customers use. Where it fits, they can share foundations with the systems behind them, so what the customer sees and what your staff see come from one source.

How we build it

Our usual stack is Angular and TypeScript in the browser, Node and NestJS behind it and PostgreSQL underneath, deployed on AWS or GCP with Docker, automated builds and monitoring in place from the first release.

Everything is typed end to end and tested where a failure would cost something. Access is least-privilege, storage is encrypted, private files are shared through signed short-lived links, and every privileged action leaves an audit trail. That is standard practice here, not a line item you have to ask for.

The work is done by senior engineers only. No offshore hand-off, no junior learning on your budget, and no layer of account management between you and the person writing the code.

Built for sectors where the details are unforgiving

Financial services, insurance, healthcare, energy and utilities, logistics, mining and retail all share one trait: the systems hold other people's money and records, answer to a regulator or an auditor, and have to keep working when conditions are not ideal. That is the kind of work we are built for, and the reason we would rather talk you out of a bad approach than bill you for it.

How an engagement runs

1. 1

   Talk to the people who would build it

   A call with an engineer, or a First Pass if you would rather gauge it first. Bring the problem rather than the specification: working out what the system actually has to do is the useful half of the first conversation.

2. 2

   Get a straight view of the work

   A written view of what we think it takes, what we would do differently, and the parts we think are riskier than they look. That includes saying so when the answer is a smaller system, something off the shelf, or no project at all.

3. 3

   Build in your repositories

   The people who scope the work are the people who write it. Commits land in your own repositories from the first week, with decisions recorded where the code can be read against them.

4. 4

   Hand over, or keep us on

   The code, the infrastructure, the accounts and the documentation are yours from the first commit, with a handover a different team could actually pick up. Or we stay on as the team that knows the system, maintaining it, extending it and keeping it secure.

Capabilities