DEV Community: Bastien GUILLAUME

One human, one studio: what the venture-studio paper gets right, and what it can't see yet

Bastien GUILLAUME — Thu, 17 Sep 2026 09:05:52 +0000

A paper came out in Technovation last month that I would have loved to read in January. Viglialoro, Sansone, Ughetto, Landoni and Lukeš mapped 1,006 venture studios, studied twelve of them up close, and asked a simple question: how does an organisation turn one person's entrepreneurial experience into a repeatable capability for creating several start-ups at once?

Their answer, in one line: a studio converts individual founder expertise into organisationally codified human capital. The moat is not any single venture. The moat is the institutionalised learning, the standardised process that runs in parallel across ventures.

I have been running a studio since January where that "organisation" is one human and a set of AI agents. Eight products built, four launching by the end of October, thirteen projects in the portfolio. No employees. I am not an academic and I am not an expert on venture studios, so take what follows as field notes from eight months, not as theory. But the paper describes, from the outside, something I have been living from the inside, and the differences are instructive.

What "codified human capital" looks like when nobody is there to hold it

In a classic studio, the codification lives in people. Founders-in-residence, a shared product team, a playbook that partners carry from venture to venture. The learning is institutional because the same humans apply it again.

In a one-human studio, that option does not exist. If the learning is not written down in a form a machine can act on, it is gone by the next project. So everything that would be a habit in a team became a file:

Standards every project must meet. A task standard that fixes the shape of every unit of work. A product definition record and a journeys file per product that say what "done" means for a user, not for a developer. A design-system document that the post-merge QA checks against. Nothing is negotiated per project.
Rails every project gets on day one. The same CI gates, the same deployment QA with two legs (one on the runner, one that drives the app through a real browser), the same release policy: nobody, human or agent, opens a release without an explicit grant.
An audit trail nobody has to remember. Every session opens a document. Every unit of work opens a task file when it starts, not after. The studio brain currently holds 3,696 task files and 532 session documents. That is the "institutionalised learning" of the paper, except that it is literal text, and the agents read it before they act.

The paper says studios extend "entrepreneurial agency and cognition from individuals to organisations". Here the cognition moved from me to a repository. The agents supply the labour. The repository supplies the memory. I supply the judgment.

Five differences from the old world

1. Parallelism is bounded by attention, not headcount. A studio with forty people can run six ventures because it can staff six teams. I can run thirteen projects because agents do not need to be staffed, but I can only decide for one or two at a time. The scarce resource inverted. The old studio rations builders. This one rations judgment.

2. The cost structure is not a smaller version of theirs. In March I had burned about two hundred euros. Today the spend is model plans and a handful of small servers. That is not a cheaper studio. It is a different object: the marginal cost of building one more product is close to zero, so the portfolio can be wider than any rational human studio would allow, and the selection happens after building, not before. "Build fast, list the pain points, park the proper solution for later" was a personal habit. It is now the operating model.

3. Learning compounds differently. In a human studio, learning compounds through people who stay. Here it compounds through rules. Every failure that reached me became a check that runs on every project after it. An agent that declared a bug fixed when it had only opened the fix became a rule that nothing counts as fixed until someone has seen it work in production. Tests that looked green while quietly ignoring problems became a rule that green is not the same as clean. None of it lives in anyone's head. None of it depends on anyone remembering. The next project inherits every lesson the day it starts.

4. Verification replaces trust. A studio partner trusts a founder-in-residence after a few ventures together. I cannot trust an agent that way, and I learned not to. In early September we discovered that several checks that were green did not prove the products worked, and the fleet sweep found one product in eight actually ship-ready. The answer was not better agents. It was a promise-versus-product page that only turns green when both QA legs pass on the released commit. The old world verifies people. This one verifies artifacts.

5. The studio itself is one of the products. Half of what got built this year is not a product for customers. It is the tick fabric that wakes workers, the bus that routes events, the task-worker that drains the queue, the deploy QA, the secrets plane. A classic studio has an operations team. This one has an operations product that had to be built before the first customer product could be trusted. That is the real "first venture".

Why it can probably be frameworked

The paper's contribution is a framework for the human studio. I think the agentic version is at least as frameworkable, for a reason the paper hints at: the mechanism is codification, and codification is what agents are good at consuming. Eight months in, the shape looks like five layers. I offer it as a hypothesis, not a result.

Intent. Mission, priorities, launch slots, release grants. Owned by the human. Written once, referenced by everything below.
Standards. What every project must look like: task shape, product definition, journeys, design system, security baseline. This is the layer the paper calls institutionalised learning, and it is where most of the year's lessons ended up.
Autonomy. The machinery that lets agents work without being asked: a queue, a scheduler, workers that claim tasks, a bus for events, a memory they can search. Without this layer the agents are tools. With it they are staff.
Verification. Gates that do not care who did the work: CI, deployment QA, the promise page, the audits that reconcile tasks against reality. This layer exists because layer 3 lies sometimes, and will keep lying in new ways.
Accountability. Session documents, task files with real statuses, one human who reads them as truth. The audit trail is not bureaucracy. It is the only thing that lets one person supervise thirteen projects without being in all of them.

Every layer is text, which means every layer can be copied into a second studio in an afternoon. That is the part I find hard to argue against: the framework is not a description of the studio, it is the studio.

What the framework cannot replace

This is where I stop pretending to know. The paper's studios are made of relationships, and the relationships are the part I have not automated and do not want to.

The first users are people who trust you. My testers are friends and former colleagues. The feedback that changed Nomi came from a lunch, not from a form. The people who will test it next got access because we worked together ten years ago.
Some markets are partnership markets. Nomi will reach small companies through their accountants or it will not reach them. No agent opens that door. The pre-payroll export exists because a human said "if you could do something on the payroll side, that would be interesting" over a plate of food.
Judgment about what "done" means is still mine. The agents can meet a standard. They cannot yet tell me when the standard is wrong. Every pivot this year (Nomi from certified payroll to pre-payroll, a product cut because it drifted into health data, a tool turned into a product) came from a conversation, not from a gate.
The paper's most human finding. Renan Devillières, who runs an operations studio in Paris, pulled one number out of it: 74 percent of the studios in the top quartile are run by former founders and operators. If that holds, the one-human studio does not remove the human. It concentrates everything on which human.

Where the two worlds meet

The interesting studio is probably not mine and not the classic one. It is a booster network of experienced operators, the people who open doors and tell you the standard is wrong, plugged into an execution layer that never sleeps and never forgets a rule. The paper says studios reduce early-stage uncertainty and hand over validated, investment-ready ventures. An agentic studio can make the "validated" part nearly free. The "investment-ready" part still needs people who have done it before.

I would rather test that with those people than write about it. If you run a studio and want to compare notes, or you have a founder with an idea and no technical team, the lunch is on me.

Eight months of field notes, thirteen projects, one human. Everything in this article that sounds like a rule was a mistake first.

ai #startup #agents #buildinpublic

Enterprise features are a tax. We paid it once, in the open.

Bastien GUILLAUME — Wed, 16 Sep 2026 14:27:50 +0000

Every B2B product hits the same wall. A prospect's IT team asks for SSO through their identity provider. Then for SCIM, so accounts appear and disappear with their HR system. Then for an audit log they can hand to a compliance officer, and a rule that says "everyone in our domain must log in through our IdP, no exceptions". None of it makes the product better for the people who use it every day. All of it is table stakes for the contract.

We run eight products. Seven of them authenticate with better-auth, each with its own copy of the same setup, its own database and its own Stripe account. Building that wall seven times was never going to happen. Buying it per connection from a US vendor didn't fit either. So we built it once, as a package every product embeds, and we published it.

@alphabros/enterprise is on npm, MIT-licensed, version 0.1.0.
Source: github.com/ShipFast-Syndicate/enterprise.

What you get

One package, four entry points, no framework-specific server code:

/server — a preset of better-auth plugins: organizations with teams and roles, SSO (SAML 2.0 and OIDC) with DNS domain verification and just-in-time provisioning, SCIM 2.0 provisioning for Users and Groups, two-factor, passkeys, API keys, and two of our own: a hash-chained audit log and an organization policy engine (require 2FA, enforce SSO with a break-glass owner, session lifetime, allowed sign-in methods, group-to-role mapping).
/schema — the Drizzle tables, a plain SQL migration, and a CLI: ab-enterprise migrate copies the migration into your project, ab-enterprise verify checks the live database has every table and column (migrations that never reached production are a real failure mode; we check after every deploy), ab-enterprise audit-verify recomputes an organization's audit chain.
/client — the matching client plugins, plus discoverHomeRealm(email): the "email first, then route to your IdP" step every enterprise login page needs.
/portal — seven Web Components (Lit) that make the whole thing self-serve for a customer's IT admin: members, an SSO wizard (paste IdP metadata, verify the domain by DNS TXT, do a mandatory test login, then enforce), SCIM tokens, security policy, API keys, and an audit viewer with CSV export and chain verification. They work unchanged in SvelteKit, Astro, Next and plain HTML, and they ship no colours, fonts or spacing of their own — you map your design tokens onto --ab-* variables.

The one thing the package does not decide is who pays for what. You pass a resolveEntitlements(orgId) function that reads your own billing plan and returns the features that organization has. Every portal endpoint answers 403 without the feature. Entitlements stay in your product; the package only enforces them.

Five minutes to a working setup

// auth.ts
import { betterAuth } from "better-auth";
import { enterprisePreset } from "@alphabros/enterprise/server";

export const auth = betterAuth({
  database: drizzleAdapter(db, { provider: "sqlite" }),
  plugins: [
    ...enterprisePreset({
      product: "myapp",
      secretsKey: process.env.ENTERPRISE_SECRETS_KEY!, // ≥ 32 chars, from your secret store
      resolveEntitlements: async (orgId) => planFeatures(await getPlan(orgId)),
    }),
  ],
});

npx ab-enterprise migrate --out drizzle   # drops the SQL migration into your folder
npx ab-enterprise verify                  # against TURSO_DATABASE_URL after deploy

<ab-security-settings org-id="org_123"></ab-security-settings>

That's the whole integration. The SSO wizard, SCIM endpoints and audit log are live behind your existing /api/auth handler.

Design choices, and why

Embedded, not central. We deliberately did not build an identity service. Each product keeps its own users, its own database and its own IdP connections. A central identity plane is a single point of failure and a user migration; we'll get there later, and the data model already leaves room for it (studio_ref columns, per-organization SSO config), but not as the first step.

Built on better-auth's own plugins where they exist. organization, sso, scim, admin, twoFactor, passkey and apiKey are upstream. We added what upstream lacks: SCIM Groups on the 1.6 line (mapped onto organization teams, with a role-mapping table), the audit chain, the policy engine, the entitlement gate, the portal, and the secrets wrapper that encrypts IdP client secrets at rest with your key (AES-256-GCM, bound to the provider row).

It runs on Cloudflare Workers. Four of our products deploy there. SAML on workerd was the open question; we proved samlify's signing and verification, encrypted assertions included, under nodejs_compat before writing a line of the package.

Tamper-evident audit log. Each organization's events form a hash chain. verify recomputes it; retention works by compaction with a chained anchor rather than deletion, so a year-old log still verifies. It's honest about its limit: someone with write access to your database can rewrite the chain, which is why the CLI exists and why we recommend exporting checkpoints.

What we did about security before publishing

We ran two audits before the first publish, one on the repository and supply chain, one on the code, and a whole-branch review after the fixes. They found real things: an audit-log injection across tenants, a role recompute that could demote an organization owner through a SCIM group change, a retention purge that broke the chain, an unused encryption key. All of it is fixed, each with a regression test that reproduces the original exploit. The production dependency tree is a single package (zod). Releases are published from CI through npm Trusted Publishing with provenance; there is no long-lived publish token. The one accepted advisory on the 1.6 line is documented in docs/security.md, with the mitigation and the test that guards it.

What it is not, yet

Pilot-grade. 0.1.0 has 397 tests and no production tenant yet. Two of our products go first; expect breaking changes before 1.0.
Pinned to better-auth 1.6.33. The SSO and SCIM plugins for 1.7 are a breaking peer change; we stay on 1.6 until the fleet moves, and the package moves with it.
Your billing, your rules. No Stripe integration, no pricing page. One function.
No central login across products. Each app is its own tenant boundary.

Contributing

Issues are open on the repository; that's the intake for now, and every issue becomes a tracked task on our side. Security findings go through GitHub's private vulnerability reporting, not a public issue. Pull requests from outside the organization aren't accepted yet; we'll open that up once the pilots are through.

If your product has been putting off the enterprise tier because it's a tax with no upside for your users, this is the tax paid once. Use it.

Alpha Bros is a studio building small B2B products from Paris. The enterprise layer is the first piece of our platform we've published; more will follow as they prove themselves in our own products.

Building an AI first Startup Studio

Bastien GUILLAUME — Tue, 23 Jun 2026 13:58:25 +0000

This post was NOT generated by AI 🤖.

Our first post was a little over two months ago. About 50 billion tokens later, we're due for an update (and we feel they were well spent).

Basically, we've spent those two months rebuilding ourselves thanks to the lessons learned from Klar launch so this post is mainly going to be technical.

Let's start with some number :

The team grew 📈 — we welcomed Spirit (Taking care of strategy and ops) and Claude (Infra), so the agent team is now 8.
We added one startup to our catalogue — Nomi, a payroll & HR solution for SMBs (an interesting one to build, because it runs straight into legislation) (coming soon to the studio landing page).
We moved from 10 projects to 30 (mainly our internals that we have been rebuilding and are finally tracking) Studio corpus today: ~1,633 tasks (~1,465 done) across those projects, an 850-feature / 83-epic / 92-defect QA tree, and ~200 decision records (50 ADRs + FDR/PRD/RFC).

We moved a lot technically :

We are nearly fully IaC: ~92% IaC-covered — ~1443 managed resources (our gap is mostly managed SaaS - Turso's DBs plus a handful of click-ops items like R2/tunnels/B2/OVH/Tailscale).
We are K8s ready (but not using it yet):
- We have containerized all our projects
- We have Kustomize manifests for all our projects
We have a full fledged deployment control plane (including an ODE)
We have continuous deployment through our entreprise bus — merge to main → event bus → the fleet reconciles and deploys.
We have continous integration : automated code review + merge across multiple orgs.
High Availability everywhere / ~120 self-healing units / 35+ scheduled jobs / a sourceS-of-truth control plane with drift detection / mostly self-hosted infra (~70% of our infra plane / 80% of our always on runtime / 100% of our compute).

We moved also product wise :

We closed ~2500 PRs (merged ~2200). Most of them (~1500) were internals (chore / fix / ci / etc.) but we have been moving on features also (384 PRs).
We have a content pipeline that produces posts and articles weekly, per project, ready to publish to X, LinkedIn, Dev.to and a custom blog — with a human in the loop when we want one (or not, of course).
We have a product pipeline constantly looking for improvements, whether in UI/UX or new features (without forgetting the bug chasing).

In the last few days the gaps have closed and everything converged where we wanted it. We're about to un-gate the main producer we paused while rebuilding — so hopefully our next post will be a launch 🚀.

Last but not least — cost: everything we've produced so far is still under the thousand-euro barrier (we only use plans for AI and we size our VMs carefully).

Bastien, for the team.

Disclaimer: this post was NOT generated by AI — but everything else was.

Test from Publishr

Bastien GUILLAUME — Fri, 03 Apr 2026 11:03:30 +0000

Test content #test