StudioMay 19, 20269 min read

Operating eight products with a team you can fit in one room

Shared infrastructure, aggressive use of AI tooling, and a hard rule against horizontal bloat. Here's how Nexobe runs eight live products without any of them feeling abandoned.

Asghar Mir
Nexobe Studio

Most product companies operate one product per founder. Nexobe operates eight. Here's the operating model that makes that math work, shared infrastructure, vertical focus, weekly shipping cadence, and a relentless habit of cutting anything that isn't earning its keep.

When I tell people Nexobe operates eight live AI products with a team you could fit in one room, the response is usually the same: "How?" The honest answer is that we've traded surface area for depth, and built a set of internal habits that compound rather than fragment.

#The math behind eight

Each product solves one specific problem for one specific user. Otteri is for serious operators who need an AI command center. AirDrv answers calls for dental practices. Nuqsaf serves the Muslim diaspora looking for Riba-free banking. The surface area of each product is intentionally narrow.

Narrow surface area means small codebases, fewer edge cases, and a roadmap that fits on one page. The unit economics of a vertical AI product, when the user is correctly chosen, are wildly better than a horizontal tool fighting for attention against Claude, OpenAI, and every other foundation model directly.

#Shared rails, separate brands

Every Nexobe product runs on the same internal platform, shared auth, shared billing primitives, shared evals harness, shared observability. Building the ninth product is dramatically cheaper than building the first because most of the plumbing already exists.

  • Shared identity layer, one sign-in pattern reused across products
  • Shared billing, Stripe customers, products, and webhooks centralized
  • Shared LLM router, model selection and fallback live in one place
  • Shared deployment, every product ships on the same Cloudflare pipeline
  • Shared eval harness, prompt regressions caught before any product is affected

#Why we refuse horizontal

Horizontal AI wrappers are a graveyard. The category is overcrowded, the moat is non-existent, and the foundation model below you will quietly subsume your feature set every six months. Vertical products win because they know one user deeply, their workflow, their language, their objections, well enough to design every decision around them.

Specificity is the moat. The more we narrow each product, the more useful it becomes, and the harder it is for a generalist tool to displace it.
Internal memo, Q1 2026

#The weekly shipping ritual

Every product ships at least once a week. No exceptions. The ritual is simple: Monday we look at what users said over the weekend, Tuesday-Thursday we build, Friday we deploy and write the weekly note. A product that doesn't ship for two weeks is in crisis, and we treat it that way.

Weekly shipping forces narrow scope. You cannot bake a four-week feature when you have a four-day window. The result is a thousand small improvements rather than three big rewrites, and a codebase that stays honest because nobody can hide behind "we'll fix it in the next quarter."

#What this model costs

The honest tradeoff is that we will never win on press-release scale. We are not the AI company that raises a billion dollars to do everything. We are the AI product company that does eight things, deeply, and operates them forever. If you want to read more about the people behind it, our about page goes into the team and history. If you want to talk to us, the contact page is the way in.

#Operations#Multi-product#Culture
Share on XShare on LinkedIn