How One Team Ships 18 Different SaaS Products
How Inite runs 18 SaaS products with one team: a shared foundation every product reuses, optional blocks they snap on, only the unique part built fresh.
One team, eighteen products
Inite runs eighteen software products: car rental, real estate, ticketed events, restaurants, wellness, an AI tutor, and more. Each one is a real business with its own customers, its own website, its own dashboard. And they are run by one engineering team.
That only sounds impossible until you notice what those eighteen products actually share. Every one of them needs user accounts. Every one needs to keep one customer company's data cleanly separated from another's. Every one needs permissions, billing, and usually a shared inbox to talk to its own customers. None of that is what makes a rental product different from a restaurant product — but it is most of the work of building either one.
So Inite builds it once.
Three layers, in plain terms
Think of every product as three stacked layers.
| Layer | What it is | Who builds it |
|---|---|---|
| Foundation | Accounts, tenants, permissions — identical for every product | Built once, reused by all |
| Building blocks | Optional pieces you snap on: inbox, billing, notifications | Shared, picked per product |
| The product | The industry-specific part: cars, properties, menus | Built fresh each time |
The foundation is the same for everyone and nobody is allowed to change it. The building blocks are a shared menu — a product that talks to customers snaps on the inbox, one that takes payment snaps on billing, and it gets a proven version instead of writing its own. The product layer on top is the only part that is genuinely unique, and it is a surprisingly small fraction of the whole.
Five foundational pieces shared by everyone. Sixteen building blocks on the shared menu. The industry-specific part built once per product. That division is why one team can carry eighteen products instead of drowning in them.
Why the four-week number is real
Across the 2026 launches — rental, real estate, shop, events — the median time from an empty project to a live customer taking payment, with one to three automated workflows running, was four weeks.
Four weeks is possible because the first two layers already exist. The team is not writing an accounts system or a billing system; those are done. Week one connects the foundation. Week two snaps on the building blocks the product needs and wires up the AI assistant. Week three builds the industry-specific screens. Week four connects payments and the messaging channels customers actually use.
The four weeks is engineering time. The part that actually decides whether a product ships happens before it: the discovery work of sitting with an operator, learning how they really work, and choosing what to automate first. That is always the real constraint — never the code.
Why it doesn't become a tangled mess
The obvious worry with sharing this much is fragility: won't one change break everything? It would, if the shared foundation held product-specific logic. That is the classic trap — a "platform" slowly absorbs every product's quirks until nothing can move without breaking something else.
The model avoids it with one hard rule. The shared foundation holds only what is genuinely identical across every product, and is never allowed to hold anything specific to cars, or property, or restaurants. Anything industry-specific is required to live in the product's own top layer, where no other product can see it. The rental product and the real-estate product share the exact same inbox and billing — but neither can reach into the other's world. The boundaries are enforced, not just politely agreed.
That is the entire idea, and it is a business one before it is a technical one. A single team looks like it ships eighteen products. What it actually ships is one foundation and eighteen thin, industry-specific tops — and each new one is cheaper and faster than the last.
Related: One engine, many skins.
01Why not just build each product separately?+
Because you would be rebuilding the same plumbing 18 times, and then maintaining it 18 times. Every SaaS product needs the same unglamorous foundation: user accounts, a way to separate one customer company's data from another's, permission rules, billing, usually a shared inbox to talk to customers. None of that is what makes a car-rental product different from a real-estate product - but it is most of the work. If each product builds its own version, a single improvement or security fix has to be made 18 times, and the versions slowly drift apart until nothing is really shared. The shared-core model builds that foundation once, proves it works, and lets every product reuse it. The team's time then goes to the part that actually differs by industry, which is a small fraction of the whole.
02What actually makes the 4-week number possible?+
The first two layers are already done. When a new product starts, the team is not writing an accounts system, a billing system, or a customer inbox - those are shared and battle-tested. Roughly: week one wires up the foundation and the tenant separation, week two snaps on the building blocks the product needs (say inbox plus billing) and connects the AI assistant, week three builds the industry-specific screens and content, week four connects payments and the messaging channels customers actually use. The output is the same shape every time - a real product an operator can hand to a paying customer. What the 4 weeks does not include, and what really decides whether a project ships, is the discovery work up front: sitting with the operator, watching how they actually work, and choosing which processes to automate first.
03Doesn't sharing so much code make everything fragile and coupled?+
It would if the shared layer contained industry-specific logic - that is the classic trap where a 'platform' slowly absorbs every product's quirks until one change breaks five products. The shared-core model avoids it with a hard rule: the shared foundation contains only the things that are genuinely identical across every product (accounts, tenants, permissions) and is never allowed to hold anything specific to cars, or property, or restaurants. Anything industry-specific is required to live in the product's own top layer, where no other product can see it or depend on it. So the rental product and the estate product share the exact same inbox and billing, but neither can reach into the other's world. The boundaries are enforced, not just suggested, which is why 18 products can share so much without becoming tangled.
04Who is this operating model actually for?+
Two audiences. For a founder or operator, it is the answer to 'how can a small team credibly run this many products' - the honest answer is that they do not build this many things; they build one foundation and a lot of thin, industry-specific tops. For an investor or partner, it is the durability story: the value is not in any single vertical but in the shared platform underneath, which means the next product is cheaper and faster than the last, and the moat compounds with each one shipped. It is deliberately not an engineering tutorial. The engineering details matter to the team building it, but the point of the model is a business one: reuse is what turns one team into a portfolio.
How We Rebuilt a 318,000-Line Car Rental CRM on Our Shared Platform in 4 Weeks
One Engine, Many Skins: 15 Vertical SaaS on Shared Runtime
