Why 9 flagships, not 30 SKUs

Manera Intelligence is built from 30+ Python sub-apps. Each runs as its own PM2 process, has its own port, its own database, its own brain. Internally we call them "petals" — they ring the central mesh hub.

But on the buying surface, you see **9 flagships**, not 30. Here's why.

The buyer-confusion tax

In 2024, when I had 30 sub-apps each with its own /pricing page, I lost deals. The objection was always the same: *"How do I know which ones I need? I don't want to evaluate 30 SKUs."*

The cost of an extra SKU isn't zero. Every additional buying decision is a ~10% conversion drop. If you have 30 SKUs each with a 50% close rate, your effective close rate on a multi-SKU deal is `0.5^N` — vanishing fast.

Our solution: collapse the 30 sub-apps into 9 flagship "buying units."

| Flagship | Sub-apps inside | |---|---| | Cyber OS | IdentityPulse, EndpointPulse, CloudPulse, PhishingPulse, AdversarialAI, ResiliencePulse, ThreatPulse | | Treasury | FXWatch, EarningsIntel, SentimentDNA, NEIP, CommodityWatch | | Strategy | MAScope, NexusAI (war room mode), PatentPulse, GeopolRisk | | Legal | LexiWorld, RegulatoryRadar, contract engine | | Real Estate | RealEstatePulse, WeatherPulse (climate risk overlay) | | NexusAI | Cross-flagship mesh-query orchestrator | | Talent Intel | Talent Intel (standalone), DrManera (assistant overlay) | | Trading | SATORI (admin-only, dormant) | | Billing | MANERAbilling (instant SKU, dev-facing) |

The buyer doesn't care that "PatentPulse" is a separate sub-app from "MAScope" — they care about *Strategy*. So we put both under Strategy and let the user decide which sub-modules to run within their Strategy flagship.

Why we kept the 30 sub-apps as modules

If 9 flagships is the buying surface, why not collapse the code too?

Three reasons:

1. Failure isolation If FXWatch's data feed breaks at 03:00 UTC, it doesn't take down EarningsIntel. Each sub-app is its own PM2 process. Treasury "works" even if 1 of 5 sub-apps is degraded. PM2 restart is a 200ms event, not a deployment.

2. Independent deploys A LexiWorld bugfix doesn't require a CloudPulse redeploy. Each sub-app has its own `app.py`, its own tests, its own release cadence. We can ship 5x/day without orchestration overhead.

3. The mesh effect Sub-apps query each other. FXWatch queries SentimentDNA queries NEIP. NexusAI queries everyone. If they were one monolith, this would be in-process function calls — fast but coupled. As 30 separate processes communicating through Redis + Postgres, they're independently scalable, independently testable, and (critically) replaceable: we can swap FXWatch's underlying engine without touching SentimentDNA.

What buyers actually see

The 9-flagship view at [/pricing](/pricing). Click Treasury, you see 5 sub-modules — but they're all included; you don't pay per module. Click Cyber OS, you see 7 sub-modules — same.

This is the buying-experience equivalent of a Mac vs a Linux distro: a Mac has hundreds of services running, but you see "System Settings → Battery." You don't see launchd. You don't want to.

Where it gets blurry

Two flagships were almost-not-flagships:

- **Trading**: I built SATORI as my personal trading assistant in early 2026. Briefly considered productizing it. Decided not to — financial advice + market-execution liability is a separate product line. Trading sits dormant on /pricing as a placeholder. Most buyers ignore it. The 1-2% who ask about it get pointed to the [waitlist](/trading). - **Billing**: Manera Billing isn't really a "buy"-side flagship; it's developer infrastructure. We surface it on /pricing because some buyers (mostly fintechs building on Manera) want to use it as their pricing layer. It's the "weird one" in the catalog.

The lesson

If your product has 30 SKUs, your conversion math is broken. If your product has 1 SKU, you're hiding optionality. Somewhere in between is the right number — for us, it's 9, and it took 18 months to land there.

The 30 sub-apps are still there. They run, they respond, they query each other. But the buyer doesn't have to think about them. That's the design.

Counterargument I've heard

> "But Bloomberg has one SKU and it works."

True. Bloomberg also has a 40-year head start on the brand. We don't. New entrants have to be more legible than the incumbent. 9 flagships organized by buyer-role-pain (CFO / CISO / GC / CSO / CHRO) is more legible to a 2026 buyer than "Manera." We earn the right to collapse to 1 SKU later, after we have brand.

What this means for you

- **As a buyer**: don't try to map our 30 sub-apps. Just pick the flagship that matches your role and start. - **As a partner / integrator**: each sub-app exposes its own OpenAPI 3.1 spec at `/api/openapi.json`. The merged spec lives at [/api/openapi.merged.json](/api/openapi.merged.json) for tooling. - **As a competitor reading this**: yes, this is a deliberate buying-experience moat. It's not technically hard. It's psychologically hard, because every PM wants to ship one more SKU.

— Kao