Three issues on building infrastructure you own, agentic systems, and the architecture behind them. This issue is about where we are applying all of it next.
For the last few years, most of the work we have done at Kivara has been for founders and operators in Western markets. Companies in the US, UK, and Europe with real infrastructure problems and the budget to solve them properly.
That work is good work. We are proud of it. But there has always been a parallel conversation happening in the background - about what it means to build the same quality of infrastructure for markets where the problems are just as real, the stakes are often higher, and the tools being used to manage them are not fit for purpose.
Sub-Saharan Africa is deploying solar energy at scale. Mini-grid operators are managing portfolios of 10, 20, 30 sites across multiple countries. Impact investors are writing cheques. Development finance institutions are providing capital. And the people running these portfolios are managing the whole thing from spreadsheets and a different portal login for every site they operate.
That is not a technology problem. It is an infrastructure problem. And it is exactly the kind of problem we know how to solve.
The problem is not that the data does not exist. It is that nobody built the layer that connects it.
01 - The Problem as It Actually Exists
A solar operator in Sub-Saharan Africa managing 20 sites does not have one system. They have 20 systems. Each inverter brand - Huawei FusionSolar, Growatt, SMA, Victron - has its own portal. Each portal has its own login, its own data format, its own export process.
To understand how their portfolio is performing on any given day, that operator logs into 20 different portals. To build a monthly report for their board or their lender, a staff member spends three to five days collecting data from those portals, reconciling it in spreadsheets, formatting it into a document, and sending it - often late.
Problems at individual sites are discovered late. Not because nobody is watching, but because nobody built the system to surface them automatically. An underperforming site might go undetected for weeks. A site that has gone offline might be flagged first by a client complaint rather than an internal alert.
Expansion decisions - where to build next, which locations look like strong candidates, where demand is unmet - are made on intuition and field observations rather than portfolio data. Because the data exists but it is not connected.
20+ Portal logins per operator per day
3-5 Days to produce one board report
80% Of sector reporting done manually
This is not a problem unique to one operator. It is the operational reality of the solar sector across Sub-Saharan Africa. And it compounds as portfolios grow. A 10-site operation can just about manage it manually. A 30-site operation cannot.
02 - Introducing SolarWatch
This is what we have been building.
A Kivara Initiative
SolarWatch
Portfolio monitoring and reporting for solar and mini-grid operators in Sub-Saharan Africa. One view of every site. Automated reports for every stakeholder. Built on the data you are already collecting.
Portfolio Dashboard
One view of performance and uptime across all sites. Alerts for offline or underperforming assets surfaced in real time.
Automated Reports
Monthly and quarterly reports for boards, lenders, and donors generated automatically from live data. Formatted and ready to send.
Revenue vs Production
kWh generated mapped against cash collected per site. Identifies collection gaps and billing discrepancies before they compound.
Expansion Intelligence
Site-level data surfaces which locations perform best and which areas look like strong candidates for new deployment.
SolarWatch sits above the inverter portals operators already use. It does not replace them. It connects them - pulling data from existing systems, normalizing it to a single schema, and delivering one view of the portfolio rather than 20 separate ones.
The reporting layer works the same way we built the agentic reporting system in Issue 003. The data sources change. The architecture principle does not. Ingest, reconcile, generate, deliver - without a staff member touching it until the approval step.
03 - Who This Is Built For
Primary Audiences
01
Solar and mini-grid operators Managing a portfolio of 10 to 50 sites across Sub-Saharan Africa. Small internal team. Reporting to impact investors or development finance institutions. Currently managing performance data and board reporting manually.
02
Impact investors and DFIs Capital deployed across multiple operators. Requiring standardized portfolio-level reporting. Currently receiving reports in different formats, on different timelines, with different levels of accuracy.
03
Climate funds and donors Needing proof of impact at scale. Tracking portfolio performance across a sector, not just a single operator. Requiring consistent, auditable reporting that holds up to external scrutiny.
The technical standard is the same. The commitment is specific. That specificity is the point.
04 - What We Are Doing Next
SolarWatch is in validation. Before we build, we are talking to operators - mapping the exact data sources they use, understanding the reporting formats their funders require, and confirming that what we have designed matches what they actually need.
If you are a solar or mini-grid operator in Sub-Saharan Africa, or if you work with operators as an investor, DFI, or fund manager, we want to talk to you before we build. Not to pitch. To understand.
And if you are a Western founder or operator who has been reading this newsletter for the infrastructure and systems content - this is where the same thinking gets applied to a different context. The architecture does not change. The problem it is solving does.
Next issue: the validation process for SolarWatch - what we are asking, what we are learning, and what it means for the build. Issue 005, Tuesday.