Last issue we introduced SolarWatch. This issue is about what happens before a single line of code gets written. The validation process, the five questions, and what the market is telling us

One of the things we have said consistently across this newsletter - going back to the first issue- is that the most expensive mistake in software is building without understanding the problem first.

That principle does not stop applying just because we are the ones building the product.

SolarWatch is our idea. We are convinced the problem is real. We have spoken to enough people in and around the African energy sector to believe that the gap we described in Issue 004 exists and that operators are feeling it. But conviction is not validation. And we will not commit to a build until we have spoken to enough operators, in enough depth, to know that what we have designed is what they actually need - not what we assumed they need.

This issue is a transparent look at how we run that process. The five questions, what we are learning from each one, and where the market signal is strong and where it is still unclear.

Infrastructure systems - the foundation before building
Cities across Sub-Saharan Africa are growing. The energy infrastructure serving them is scaling too. The operational layer sitting above it has not kept pace.
Conviction is not validation. We will not build until we understand the problem the way operators understand it - not the way we imagined it.

01 - Why Validation Comes Before Everything

Every build we have done at Kivara - the agentic reporting system in Issue 003, the legacy migrations, the operational platforms - has started with a discovery phase. We do not scope before we understand. We do not build before we scope.

SolarWatch is no different, except that the discovery phase is longer and the stakes of getting it wrong are higher. We are not building for a client who is in the room with us. We are building a product for a market that is geographically distributed, operationally diverse, and underserved by existing tools in ways we are still mapping.

The validation phase for SolarWatch has one goal: answer five questions with enough specificity that we can make a confident build decision. Not a hopeful one. A confident one.

We are targeting five operator conversations before we commit. Each conversation uses the same five questions. The answers will either confirm the build, reshape it, or tell us we have misunderstood something fundamental about the problem.

Target operator conversations

Questions per conversation

Lines of code written so far

The Five Questions

These are not discovery call questions designed to qualify a prospect. They are research questions designed to test a hypothesis. The distinction matters. We are not trying to close anyone. We are trying to understand whether what we have built in our heads matches what operators actually experience.

Q1- How do you currently track performance across your portfolio - what tools, how long does it take, and where does it break down?

This is the foundation question. We need to understand the actual process - not the process as described in a pitch, but the real day-to-day workflow. Which portals. How many logins. Who does it. How long it takes. Where the data is unreliable. Where the process breaks under pressure.

What we expect to hear: multiple portal logins, spreadsheet reconciliation, data that does not always match across sources, a process that was manageable at 5 sites and is becoming unmanageable at 20.

Signal: Strong

Q2- What does your monthly board report look like and how long does it take to produce? Who builds it?

The reporting burden is the sharpest pain point we have identified. This question tests whether that is true for the operators we are talking to. We want to understand who owns the process, how many hours it takes, what format the output takes, and whether it goes out on time or late.

We also want to understand who the stakeholders are - whether it is a board report, an LP update, a lender covenant report, or a donor impact summary. Each audience has different formatting requirements, which shapes the SolarWatch output layer significantly.

Signal: Strong

Q3- When you want to understand where to expand next, what information do you use and where does it come from?

This question tests the expansion intelligence feature of SolarWatch. Our hypothesis is that expansion decisions are currently made on intuition and field observations rather than portfolio data - because the data exists but is not connected in a way that makes it useful for this purpose.

What we are less certain about: whether operators are actively making expansion decisions right now, or whether this is a future need rather than a current pain. If it is the latter, it should be deprioritized in the MVP scope.

Signal: Mixed

Q4- Which inverter brands and payment systems are you using across your sites?

This is a pure data mapping question. SolarWatch’s ingestion layer needs to connect to the systems operators actually use. We have a working hypothesis - Huawei FusionSolar, Growatt, SMA, and Victron are the dominant inverter brands in Sub-Saharan Africa - but we need to confirm this against real operator portfolios before we build the integrations.

The payment system question is equally important. Mobile money platforms vary significantly by country. What works in Zambia is different from what works in Kenya or Nigeria. The answer here directly shapes the revenue versus production mapping feature.

Signal: Pending

Q5- If a tool did this automatically, what would you pay for it monthly - and who in your organization would make that decision?

The willingness to pay question is always the hardest and the most important. We ask it last because by the time we reach it, the operator has described their problem in their own words. The question lands differently when it follows a detailed account of how much time and effort the current process takes.

We are not anchoring to a price point before we ask. We want to hear what operators volunteer before we offer a range. The decision-maker question matters equally - in a small operator with three to ten staff, the person managing the reporting process and the person who approves software spend may be the same person, or they may not be.

Signal: Pending

Analytics and data insights dashboard
Solar deployments like this one are being managed across portfolios of 10, 20, 30 sites - with no single system connecting them.

03 - What the Market Is Telling Us So Far

We are early in the process. The conversations have not all happened yet. But from the outreach we have run and the early signals we are picking up from people in and around the sector, here is an honest picture of where things stand.

Early Market Signals

The reporting pain is real and immediate Operators who understand what SolarWatch does immediately connect it to a problem they are living with. The monthly reporting cycle is the sharpest hook. It does not need much explanation.

The portfolio dashboard needs more context 

Not every operator immediately sees the value of a unified performance view - particularly smaller operators who manage their sites with more hands-on oversight. This feature may need to be framed differently for operators under 10 sites.

Funder requirements are driving urgency 

The operators most interested in SolarWatch are the ones with the most demanding funder reporting requirements. DFI-backed operators in particular are spending disproportionate time producing reports in formats their funders specify. This is the highest-urgency ICP.

Trust before technology 

Some operators are cautious about a new tool from a team they do not know yet. This is not a product objection. It is a relationship dynamic that is normal in markets where vendors have overpromised and underdelivered. The AfroInnovate brand separation is the right call - but brand alone is not enough. Presence and proof matter.

Expansion intelligence is a longer-term need

Early signals suggest that expansion decisions are not the most pressing pain for most operators right now. Portfolio monitoring and reporting automation are the immediate needs. Expansion intelligence may be better positioned as a roadmap feature rather than an MVP feature.

The Honest Read

The market signal on SolarWatch is not uniformly strong yet. The operators who get it immediately get it very quickly - the problem resonates, the solution makes sense, and the conversation moves fast. But not every operator gets there without more context.

That is not unusual for a product at this stage. It tells us something about the ICP - the operators most ready for SolarWatch are the ones managing the largest portfolios, reporting to the most demanding funders, and feeling the most acute time pressure. That is who we are designing for first.

We are not reading the mixed signal as a reason to stop. We are reading it as a reason to stay in validation until we have enough conversations to know exactly who the product serves best - and to design the first version around that operator, not the broadest possible version of the market.

Global data network and infrastructure
Validation is fieldwork. Five conversations, five questions, one goal - understand the problem the way operators understand it before writing a single line of code.

04 - What Happens After the Five Conversations

When the five validation conversations are complete, we will have one of three outcomes.

The first: the signal is strong enough across all five questions to confirm the build. We scope the MVP, fix the price, and start. That is the outcome we are working toward. It requires the conversations to confirm that the reporting pain is consistent, the willingness to pay is real, and the data sources we are planning to integrate are the ones operators actually use.

The second: the signal is strong on some questions and unclear on others. In that case we reshape the MVP scope - deprioritize the features where the signal is weak, double down on the ones where it is strong, and run a second round of conversations on the unclear points before committing to a build.

The third: the signal tells us we have misunderstood something fundamental. The problem exists but in a different shape than we assumed, or the ICP is different from the one we were designing for. In that case we go back to problem framing before we go anywhere near a build.

We are publishing this process because we think it is worth showing. The discipline of not building before you understand is something we tell every client at Kivara. It would be dishonest to skip it ourselves.

We will not build until the signal is clear. That is not caution. That is the only way to build something worth using.

Next issue: the validation results. Five conversations done, five questions answered. What we learned and what we are building. Issue 006, Tuesday.


Solar or mini-grid operator in Sub-Saharan Africa? We want your five minutes before we build.

DM Or reply to this directly.