From Ampora to Ventora: Reusing a Product Blueprint

Building the second product in a family is a test of how well you understood the first one. If the second takes as long as the first, you did not build a blueprint, you built a one-off twice.

Ventora came together substantially faster than Ampora. Here is the accounting.

What was genuinely reusable

The architecture. Retrieval grounded in a curated corpus, citations carried end to end, deterministic calculators alongside the assistant. That shape did not change at all.

The interface language. Big touch targets, dark UI for bright-and-dark environments, calculators as first-class screens rather than buried tools.

The infrastructure. Auth, subscriptions, the API layer, analytics, the release pipeline. This is the boring half of an app and it transferred almost entirely.

The evaluation discipline. Not the test cases — those are trade-specific — but the framework for what to test and who reviews it.

What had to be rebuilt

The corpus. Obviously. But more than expected: HVAC reference material is structured differently from electrical code, so the ingestion work was not a parameter change, it was a rewrite.

The calculators. Six new ones, each needing verification against worked examples from the manuals. No shortcuts available.

The refusal behaviour. As covered elsewhere, HVAC requires deferring to equipment far more often than electrical does. That is a content and prompt change, not a config toggle.

The domain review. You cannot reuse an electrician to check HVAC answers.

The rough split

Roughly speaking, the platform was reusable and the domain was not. That maps to about half the work being genuinely saved.

The mistake would have been assuming the domain half was smaller than it is. Everything that makes the product trustworthy lives in the domain half. It is the expensive part, and it should be.

The trap we avoided

The tempting move after Ampora was to build one app with a trade selector. One codebase, one App Store listing, pick your trade on first launch.

We did not, for three reasons:

• Discovery. An electrician searching the App Store is not looking for a multi-trade tool.
• Focus. Every screen would have to be conditional. The interface gets worse for everyone.
• Trust. A tool that claims to know six trades reads as knowing none of them well.

Two focused apps beat one general one, even at the cost of duplicated infrastructure.

What this means for the next one

The blueprint is now real: a documented architecture, a shared component approach, and a checklist for what a new trade requires. The next product in this family should be faster again.

But the domain work will not shrink, and we would be suspicious of ourselves if it did.

See the results: Ampora and Ventora.