Why we build one company at a time

The usual model

A typical agency or studio sells hours. To keep a team of twenty busy it needs a steady pipeline of clients, so every project gets a share of the people: a designer on Tuesdays, an engineer who is also fixing someone else's release, a lead who joins the call and leaves early. Nothing about that is dishonest. It is how the economics work when the product is time.

The cost shows up in the work. Context leaks every time someone switches projects. Decisions wait for the one person who understands the system. Problems a focused team would fix in an afternoon sit in a backlog for a sprint.

What we do instead

We take on one company at a time. The whole team, research, design and engineering, works on a single product until it is live and growing. Then, and only then, we take on the next one.

That constraint changes how a build runs:

• Decisions happen in the room. The person who designs a flow sits next to the person who builds the API behind it, so most questions are answered in minutes.
• Nothing is handed off. The people who scope the product are the people who ship it, so nothing gets lost between a strategy deck and a pull request.
• Research is part of the build. When a product needs it, applied research runs alongside the engineering rather than as a separate engagement. DAGI and Project Nemesis both came out of that way of working.

What it costs us

Mostly, saying no. We turn down far more work than we take on, including projects we would enjoy. It also means a founder sometimes waits for the current build to land before we can start. We would rather say that plainly in the first conversation than start late and split the team.

It also puts our name on the outcome. We put in our time and reputation, and often capital, so we only win when the product does. That alignment is the point.

Who it suits

One company at a time works best for founders and companies who:

• have a product that needs several disciplines at once, such as AI infrastructure, a regulated financial product or a full SaaS build;
• want one accountable team rather than a set of vendors to coordinate;
• care more about the product being right than about the lowest day rate.

It suits less well if you need a small piece of work done next week, or extra engineers for your own team for a few months. Plenty of good firms do that well.

How to start

The first step is a short application: what you are building, and why now. We read every one and reply within 48 hours. If there is a fit, we spend a week inside the problem before anything else, and we have written about what that first week looks like.