Why Northlea exists

Built around the business, not the technology.

Northlea was founded on a simple belief: technology only creates value when it improves something that matters economically.

That belief comes from experience across finance, banking, technology and business ownership. Different environments, but the same recurring question:

What is really driving the outcome, and what would materially improve it?
Tonderai Kachecha, founder of Northlea Consulting.
Tonderai Kachecha, CA(Z)Founder / Northlea Consulting

Different environments. The same commercial question.

Northlea was founded by Tonderai Kachecha, a Chartered Accountant whose career has crossed audit, banking, treasury, financial control, technology and business ownership.

Each of those experiences provided a different way of looking at a business. Finance taught me to follow the economics, technology taught me how systems get built, and business ownership taught me how quickly small operating problems become expensive when they are seen too late.

Those three lessons sit at the centre of how Northlea works today.

FinanceFollow the economics
TechnologyBuild around the problem
Business ownershipSee problems early

The numbers are the result. The real work is understanding what created them.

Training as a Chartered Accountant and working across audit, banking, treasury and financial control taught me to look beyond the financial statements.

Revenue, margin, cash and risk are outputs of decisions being made throughout the business. To understand why the numbers are moving, you need to understand what is happening underneath them.

Where is demand coming from? Which customers are genuinely profitable? Where is working capital being absorbed? What is creating risk, and which decisions are driving the eventual financial result?

That way of thinking is still the starting point for Northlea.

Follow the economics before you prescribe the solution.

A good system begins before anyone writes code.

For four years, I worked as the subject-matter expert on an internal banking platform designed to help manage interest-rate risk across the banking book.

The underlying problem was complex. Fixed-rate assets such as mortgages, personal loans and vehicle finance created exposures that had to be managed using instruments such as interest-rate swaps, while making sure portfolios were not materially over-hedged or under-hedged.

My role sat between the business problem and the technology team.

I helped define requirements, translate treasury needs into something developers could build, work through the implementation, lead user acceptance testing and report progress to senior stakeholders.

That experience taught me something important.

The quality of the technology depends heavily on the quality of the problem definition.

If the objective is unclear, the requirements will be unclear. If the decision the system needs to support is poorly understood, even excellent software can solve the wrong problem.

01Business Need
02Requirements
03Build
04Test
05Operational Use
Technology should be the consequence of understanding the business, not the starting point.

Some lessons only become real when it is your cash on the line.

I later bought and operated two businesses in the plumbing industry. One was a contracting business, the other a plumbing merchant.

Neither ultimately worked out.

Running them taught me lessons that are much harder to learn from a spreadsheet.

Cash flow problems rarely arrive suddenly. Stock begins to build, customers take longer to pay, margins narrow, capacity gets stretched or jobs begin absorbing more resources than expected.

The signals are usually there before the pain becomes obvious.

The problem is whether the business can see those signals early enough to act.

A stock issue identified today might require a change in purchasing. The same issue discovered three months later may require discounting, additional borrowing or a write-off.

A customer beginning to pay more slowly may be manageable when the pattern first changes. It becomes a very different problem once the outstanding balance has grown.

A problem spotted early is often manageable. The same problem discovered late can become existential.

That combination matters in African enterprise work.

Finance, operations, technology and data are often treated as separate conversations. In practice, a commercial decision moves through all four.

Northlea exists to work across those boundaries. The finance background keeps the work anchored in economics. The systems experience helps translate operating requirements into something that can actually be built. Business ownership keeps the focus on timing, cash and the cost of discovering the problem too late.

That is particularly useful in environments where management has to make decisions with fragmented information, volatile operating conditions and systems that were not necessarily designed around the local commercial reality.

The operating environment is not a footnote. It changes the system you should build.

Northlea is focused on African businesses because the realities of those markets often do not fit neatly into assumptions developed elsewhere.

Useful information may be fragmented across formal systems, mobile payments, spreadsheets, WhatsApp, field teams, transactions and human operating knowledge. The problem is not simply data quality. It is deciding which signals matter, how quickly they can be made useful and what management should do differently because of them.

That combination of commercial judgement and systems thinking is the work Northlea is being built to do.

Agricultural activity in Limpopo, South Africa.
Limpopo, South Africa. Photo: Tshedza Muvhango / Unsplash.

Ongoing commercial analysis

The thinking does not stop when the engagement ends.

The Tuesday Northlea Note is where I write about the commercial questions sitting underneath technology adoption: decision-making, cash, risk, operating systems and the realities of building businesses across African markets.

It is deliberately practical. The aim is not to celebrate technology. It is to understand where the economics move and what management should notice earlier.

Recent note

Do you make this mistake when someone mentions AI?

A short argument for treating AI neither as a threat nor as magic, but as an operating question that has to earn its place inside the business.

Read & subscribe