Approach

How we actually build

Venture studio describes very different operations. This is the specific version we run in Oslo, including the parts that do not work.

We start companies, we do not fund them.

Arc Labs is not an investor. We do not evaluate other people’s companies and write cheques. Every venture in the portfolio started here, from a problem we picked, and was built by us. That changes what we optimise for. We are not looking for the company most likely to raise a round. We are looking for the problem most likely to still be worth solving in three years.

The pattern that repeats

01

Pick a problem you can say in one sentence

If the problem needs a paragraph to explain to the person who has it, it is not one problem yet. Dishy exists because "the dishes pile up and cleaning services want a contract" is a complete thought. Every venture here started as a sentence that someone nodded at.

02

Learn the domain before writing the product

For the property tax work this meant reading actual statutes, county filing rules and evidentiary standards across states, not skimming three competitor landing pages. The research is unglamorous and it is where the real advantage sits, because most people building in a space have not done it.

03

Build the smallest thing a real person could use

Not a prototype and not a landing page with a waitlist. The smallest version that a stranger could complete an actual task with, because that is the only thing that generates honest information about whether the idea holds.

04

Keep it, kill it, or let it run quietly

All three are legitimate. The mistake studios make is treating every venture as needing constant momentum. A product that works and does not need daily attention should be left alone, not force-grown to justify the effort already spent on it.

What carries between ventures

Judgement, mostly

How long to wait before killing something. Which technical shortcut costs you later and which one never matters. How to tell a real signal from a polite one. That compounds across ventures in a way that is genuinely useful.

Not the codebase

Shared code across genuinely different products is mostly a studio fantasy. A household services marketplace and an equities trading system have nothing meaningful in common. Pretending otherwise produces abstractions that fit neither.

The honest failure mode

Running several ventures at once risks none of them getting the attention a single company would have had. That risk is real and being organised does not fully solve it. What we actually do about it is allow a venture to sit still, and accept that not everything can be the thing we are pushing this quarter.