Why we run several products under one company

Tulmira Ltd ships four products. People reasonably ask whether that is focus or a lack of it. This is our answer, including the parts that count against us.

What we share

Every product runs on the same foundations, and that is the whole argument for the structure.

• One deployment pipeline, one set of monitoring dashboards, one on-call rota.
• One authentication and audit-logging approach, reviewed once and reused.
• One legal entity, so one privacy policy, one set of terms and one place to send a data request.

Standards, not code

We do not share a giant internal framework. We share decisions: how secrets are stored, how an API error looks, what a changelog contains. A decision is cheaper to carry than a dependency.

What it costs

Context switching is real. A week split across a hiring product, a vault and a developer tool means none of them gets a full week. We accept slower feature velocity on each in exchange for lower fixed costs on all of them.

Risk is also coupled. A serious incident in one product takes our attention from the others, and a reputation problem in one is a reputation problem for the company.

Why not separate companies

Separate entities would give cleaner accounting per product and cleaner exits. They would also mean four sets of filings, four bank accounts and four of everything else, for a team that fits in one room. We would rather spend that time on the work.

The rule we use to say no

A new product has to pass three checks before it gets built:

1. It reuses at least two of the shared foundations.
2. One person can hold the whole thing in their head.
3. We would use it ourselves.

Most ideas fail the second check. That is the point of it.

What would change our mind

If one product grows to need its own team, its own roadmap meetings and its own compliance work, it should probably become its own company. We would rather make that call early than let it blur.