Last issue we published the five questions we ask before we build anything. This issue is a case study in what happens when you apply that discipline - and an update on where SolarWatch stands.
There is a version of every product build that looks like this: a founder has an idea, someone starts building immediately, and six months later they have something that works technically but does not quite fit the market they were building for. We have seen that pattern more times than we can count.
Inara was the opposite of that. When the brief came to us, the core question was not what to build - it was how to build it in a way that could be shipped fast, scaled cleanly, and extended without a full rebuild when the product needed to grow.
A wellness and mindfulness app, both iOS and Android, concept to deployed product, under eight weeks. Those constraints sound like the setup for a compromised build. They were not. They were the conditions that forced the right decisions early.
This is the story of those decisions - and why the ones that looked like they were slowing us down were the ones that made the difference.
01 - The Inara Build
Kivara Case Study
Inara - Wellness and Mindfulness App
iOS and Android • MVP from concept to deployed product • Under 8 weeks
The brief was tight. A wellness and mindfulness app with a clear core function, a defined user flow, and a hard deadline. Both iOS and Android. No phased release - both platforms needed to ship simultaneously.
The first thing we did was not open a code editor. It was map the data model. What does the app need to store, how does it change over time, and what does the API layer need to look like for the features that are not in the MVP but will be in version two. That conversation took two days. Those two days saved six weeks of rework later.
Speed in a build like this does not come from skipping decisions. It comes from making the right decisions early and then moving fast inside a clear structure. Every day we spent on architecture was a day we did not spend rebuilding something that was built wrong.
8 Weeks concept to deployed
2 Platforms shipped simultaneously
0 Post-launch architecture rebuilds
The constraint that pushed the hardest was the simultaneous iOS and Android requirement. The easy path was to build iOS first, ship it, then port to Android. We did not take it. We built a shared logic layer from the start - one codebase driving both platforms, with platform-specific UI components sitting above a common data and business logic foundation.
That decision cost time upfront. It saved significantly more time after launch, when updates, fixes, and new features could be shipped to both platforms in a single cycle rather than two separate ones.
02 - The Three Decisions That Mattered
Every build has a handful of decisions that shape everything that comes after. In the Inara build there were three. None of them felt dramatic at the time. All of them turned out to matter significantly.
01
Data model before features
We designed the data schema before scoping a single feature. The question was not what the app does today - it was what the app needs to be able to do in twelve months without rebuilding the database. Wellness apps accumulate longitudinal user data. If the schema is not designed to handle that from day one, every future feature that touches historical data becomes an expensive migration.
02
Shared logic layer across both platforms
Building iOS and Android simultaneously is a constraint most studios solve by building twice. We solved it by building once at the logic layer and twice at the presentation layer. Business rules, data handling, and API communication live in shared code. Platform-specific UI sits above it. The upfront cost was real. The ongoing maintenance cost dropped significantly - one fix, two platforms, one release cycle.
03
Scope discipline - build the core, defer the rest
The MVP scope was agreed and locked before build started. Every feature request that came in during the build was logged, prioritized, and deferred - not added. The temptation to include one more thing is the most common reason MVPs ship late and ship bloated. Inara shipped on time because the scope did not move. The deferred features went into a documented backlog that became the roadmap for version two.
Speed in a constrained build does not come from skipping decisions. It comes from making the right ones early and moving fast inside a clear structure.
03 - What the Inara Build Demonstrates
The Inara case study is not primarily a story about speed. Eight weeks is fast for a dual-platform MVP, but speed was the constraint, not the goal.
It is a story about what becomes possible when you own the architecture rather than adapting to someone else’s platform. A no-code tool could not have produced the shared logic layer. A vibe-coded build would not have produced a data model designed for longitudinal user data from day one. Those decisions required deliberate design before anyone opened a code editor.
It is also a story about scope discipline. The features that did not ship in the Inara MVP were not cut because they were unimportant. They were deferred because shipping a focused product that does one thing well is more valuable than shipping a bloated product that does several things adequately. Every feature in the MVP we build at Kivara earns its place by serving the core question: does this help answer whether the product solves the problem well enough that people will use it consistently.
That discipline - data model first, scope locked, architecture designed for where the product is going not just where it is today - is what we carry into every build. Including the one we are validating right now.
04 -Update - SolarWatch Validation
SolarWatch - Validation In Progress
Since Issue 005, validation outreach has begun in earnest. We have identified the first wave of operators to speak with - solar and mini-grid operators managing portfolios of 10 to 30 sites across Sub-Saharan Africa, with active funder reporting requirements. Conversations are being scheduled.
The outreach framing is working better with operators who have DFI or impact investor reporting requirements. The reporting burden resonates immediately with that profile. Operators with less formal funder relationships need more context on the portfolio dashboard value before the conversation accelerates.
That is consistent with what we described in Issue 005. The ICP is sharpening as we go. The operator most ready for SolarWatch right now is managing 15 or more sites, reporting to at least one formal funder, and spending meaningful staff time every month producing reports manually.
Positive Signal
DFI-backed operators engage immediately. Reporting pain is the hook. No explanation needed once they understand the automation angle.
Still Developing
Smaller operators and those with informal funder relationships need more context. May be a roadmap segment rather than a launch ICP.
The five validation conversations are the target before any build commitment is made. We are not rushing that process. The Inara build story above is a reminder of why the decisions made before writing code are the ones that matter most.
05 - The Common Thread
The Inara build and the SolarWatch validation process are connected by the same principle that has run through this newsletter since Issue 001.
The decisions that determine whether a product succeeds are not made during the build. They are made before it. The data model. The scope. The architecture choices. The ICP. The questions you ask before you write a single line of code.
Every issue in this series - from the agentic AI argument to the reporting system architecture to the SolarWatch validation process - has been making the same case in different contexts. Build with intention or pay to rebuild without it. That is the whole argument.
Next issue we will have the first real signal from the SolarWatch operator conversations. What we asked, what they told us, and what it means for the build decision.
Next issue: the first operator conversations are done. What we learned from the five questions and what it means for SolarWatch. Issue 007, Tuesday.