What a Venture Studio Actually Does

"Venture studio" gets used loosely these days, often as a smarter-sounding way of saying "we back start-ups" or "we run an accelerator." It is neither of those things. A venture studio builds the companies itself, from the first commit to the first paying customer, using one team and one shared set of tools. At Unavoidable Studio we run several software products in parallel rather than staking everything on one, and after a few quarters of doing this in the open, here is what the model actually looks like from the inside.

Not a fund, and not an incubator

A fund's job is to pick companies that already exist and support them from a distance. An incubator hosts outside founders for a fixed programme and then sends them on their way. A venture studio does neither. It originates the idea itself, hires or assigns the first engineers and designers itself, and keeps building long after the idea stage is over. The studio behaves like the founder for every product it starts, which is the main thing worth understanding before anything else: a venture studio is an operating business that happens to run more than one product, not a vehicle that happens to touch several companies from the outside.

One platform, several products

Running more than one product only works if most of the underlying machinery is shared rather than rebuilt from scratch each time. For us that means one design system, one approach to logins and billing, one deployment pipeline, and one way of handling a support reply, reused across the products in our Portfolio. Have a look at the current line-up and you will notice the family resemblance under the surface, even though each product serves a very different customer. A new product does not start from an empty folder. It starts from a base that already has authentication, payments, analytics and a component library wired in, which is the whole point.

Reused infrastructure means faster starts

The first few weeks of any new product are usually spent on plumbing nobody will ever see: user accounts, password resets, invoicing, basic analytics, a way to deploy without breaking production. None of that is where the interesting work happens, and it barely differs between one small business tool and the next. Doing it once, properly, and reusing it every time it is needed again is the single biggest reason a small team can run several products at once without each one taking twice as long to reach its first customer.

Lessons move between products

Building an AI receptionist for one product teaches you things about handling messy, real-world customer conversations that turn out to be directly useful when you are designing automated replies for another. A savings product built for families forces a level of care around data handling that then raises the bar for every other product in the studio, not just the one it was built for. None of this cross-pollination happens automatically. It happens because the same small group of people is working across all of it and can spot the pattern the second time it turns up.

How the day-to-day actually works

In practice this looks like small, focused pods, often two or three people, each responsible for a single product, checking in briefly and often rather than sitting through long weekly stand-ups. Roadmap decisions get made close to the work rather than in a separate planning layer above it. We write up what shipped and what we learnt as we go, partly so the next product does not repeat the same mistake, and partly because building in public keeps everyone honest about what is actually finished versus what merely looks finished in a screenshot.

What this looks like in practice

At the time of writing, one product is live and taking real customers, one is fully built and close to launch, a couple are at MVP or pre-launch stage, and two are earlier, more ambitious swings still in build. That spread is deliberate. A studio running several products at different stages does not need every single one moving fast in the same month, because the quiet weeks on one product are usually the busy weeks on another. You can see exactly where each product stands on the portfolio page, updated as things change rather than left to go stale.

Who this approach actually suits

This model suits people who get more satisfaction from shipping and iterating repeatedly than from one long build-up towards a single launch. It suits operators who like variety in their working week and are comfortable holding several different customer problems in their head at once. It does not suit anyone looking for a shortcut to move faster than a focused, single-product team could, because on any one product, a team that only works on that product will usually out-execute a team splitting its attention several ways. The advantage of a studio is not raw speed on any one thing. It is resilience across several things, plus a platform that gets a little better every time it is reused. You can read more about how we think about this on the About page.

The trade-offs nobody puts on the homepage

Running several products in parallel has real costs, and it is worth being straightforward about them rather than only selling the upside.

• Context-switching is genuinely tiring. It is easy to underestimate how much focus it pulls away from any single product in a given week.
• The shared platform has to be good. A mediocre shared platform does not save time. It just spreads a slower, weaker foundation across every product built on top of it.
• Distinct brands take discipline. Keeping several products and customer bases straight, without the whole thing feeling like a jumble of unrelated ideas, takes more ongoing effort than most people expect when they first hear the pitch.

This is the first post on our blog. We will keep posting as we ship, learn and occasionally get things wrong. Back to the blog.