One Engine, Many Skins: The Inite Thesis on Shipping 15 Vertical SaaS Products on Shared Runtime

Fifteen products, one engineering team

By May 2026 Inite ships fifteen vertical SaaS products: car rental, real estate, agentic commerce, ticketed events, longevity wellness, AI tutor, restaurants, travel, sports clubs, community, AI visibility, content publishing, cover generation, pitch decks, consultancy. Each one is a full multi-tenant SaaS with its own customers, marketing site, KPI dashboard. They share auth, billing, the multi-tenant inbox, the LLM assistant runtime. They share no lines of domain code.

The number that matters is four. Across four 2026 deployments — rent, estate, shop, events — the median calendar time from empty repository to live tenant taking payment, with one to three automated workflows running in production, was four weeks. Engineering, four weeks. Customer-side discovery — interviewing operators, capturing real workflow data, choosing which processes to automate first — takes longer and decides whether the four engineering weeks ever happen.

How fifteen products fit one engineering team is what this post is about.

The shared bones

Every vertical implements the same five core entities: a user, a tenant, the user's role inside that tenant, an API key, and a per-user permission override. From there it declares which optional capability bundles it consumes — an inbox if it talks to customers in chat, a billing module if it takes payment, a storefront builder if its tenants need a public-facing site, an incidents pipeline if its operators need an alert queue. Below those, each product owns its own domain: vehicles for rent, properties for estate, events and tickets for the ticketing product, restaurants and menus for the food product.

Five entities shared by everyone. Capabilities chosen per vertical. Domain owned by the vertical. The interesting question is how that division gets enforced — and how the platform stops itself from absorbing things that belong to the product.

Three layers, not two

A typical shared-platform setup has two layers: a runtime library every product imports, plus the products themselves. It works until two products disagree about what an entity should look like. One product calls its end-customer customer, another calls the same thing lead, the shared inbox tries to handle both, and the shared inbox ends up subtly broken in both directions.

Inite splits the platform three ways. A spec repository ships no executable code at all — only the schemas, validators, and manifest templates that define what a vertical must declare to join the ecosystem. A runtime SDK implements those declarations identically for every product that adopts them. The fifteen vertical products inherit the runtime and apply the contract to their specific domain.

Calling these three layers a constitution, a government, and citizens is the metaphor. The mechanical effect is that contracts get validated before code ships. Both the rental product and the estate product declare the shape of their end-customer entity against the same schema. The validator rejects mismatches. The shared inbox knows nothing about cars and nothing about properties; it knows about conversations, messages, and channel adapters, and refuses to reach into the domain layer of any product.

What four weeks of cloning looks like

Week one stands up the multi-tenant scaffolding and the five core entities. Week two pulls in the capability bundles the vertical needs and wires the LLM-driven assistant. Week three builds the per-vertical screens, configures the storefront preset, ships the AEO content surface so AI assistants can see the product. Week four connects payments and channel adapters (Telegram, WhatsApp, web), then opens the agent-callable interfaces that let Claude or ChatGPT drive the product directly.

The output is the same shape every time: a multi-tenant SaaS an operator can hand to a real customer on launch day. Week-by-week breakdown drifts in detail between deployments. The four-week cadence holds.

The four weeks are engineering cost. Discovery cost lands before engineering starts and is the real constraint — and it is also the cost that decides whether a project ships at all.

inite.fund is outside this stack

inite.fund does not run on the SaaS platform. It is an autonomous portfolio control plane for operators trading their own capital on their own venue keys — trading positions, an encrypted vault for venue credentials, a hash-chained audit log of every action, an MCP-callable approval queue with human-in-the-loop. The multi-tenant SaaS shape does not fit any of that. inite.fund does not implement the five core entities and does not consume the shared runtime.

The architecture underneath shares the operating philosophy: explicit contracts on every boundary, audit-chained state, no irreversible action without a human acknowledgment. inite.fund runs on a Python and Go stack with zero shared code with the SaaS runtime. The SaaS platform proves the model on fifteen tenants; inite.fund proves the same operating discipline generalizes outside the multi-tenant SaaS shape.

Why this is the moat

Per-vertical SaaS companies compete on domain depth and each rebuild the same plumbing. Horizontal platform companies compete on breadth and leave the domain to customers. Either model rarely scales to fifteen products on one engineering team.

A spec-plus-runtime model competes on a different axis. One engineering team moves at the speed of a horizontal platform and ships at the depth of a per-vertical company. The fifteen products are go-to-market bets sitting on top of a single engineering substrate. When a vertical proves a market, the engineering for the next adjacent vertical is four weeks. When a capability proves itself — a new billing flow, a new channel adapter, a new agent integration — every product that opts in inherits it without any vertical-specific work.

That accumulates. The fifteenth product takes the same four weeks as the second. The companion post on the AEO diagnostic engine (how Inite builds vertical AI products) covers the visibility product that inite.ai ships, one of fifteen. This post is the operating model underneath all of them.