---
title: "Creating a Project"
description: "How a new Project starts, when it has to be paid for, what it inherits from the workspace, and what it does not inherit."
updated: "2026-08-29"
verifiedAgainst:
  - packages/shared/src/index.ts
  - apps/web/lib/server/onboarding-status.ts
  - packages/shared/src/free-grant.ts
  - packages/shared/src/trial.ts
  - packages/shared/src/project-plan-selection.ts
  - packages/shared/src/blog-publication.ts
  - apps/web/app/api/sites/create-project/route.ts
  - apps/web/app/api/bootstrap/route.ts
  - apps/web/lib/server/project-setup-contract.ts
  - apps/web/lib/server/site-tiers.ts
  - apps/web/lib/server/project-publication.ts
---

A Project is created from the workspace switcher. There is no way to create one
that is already running.

Where payment sits in its setup is not the same for every Project, and the rule
is not simply "first is free, the rest are paid". A workspace already on a paid
subscription adds Projects in the ordinary order, scan first. A workspace still
running its Free Project pays before setup for the sibling it adds. The table
under [the sequence](#the-sequence) sets every case out.

## What a new Project starts with

<PropertyList>
  <Property name="Nothing editorial">
    No strategy, no directions, no topics, no knowledge, no assets. Each Project
    describes one product, and evidence from another product would be worse than
    none.
  </Property>
  <Property name="Its own plan">
    Chosen at its own plan step. It does not inherit the plan of an existing
    Project, and it does not receive a second Free grant or a second trial.
  </Property>
  <Property name="Its own blog">
    A fresh `blogged.dev` address. A first Project carrying a signup benefit has
    a live blog from creation. Every other case is held back until setup
    completes, except a directly invoiced workspace, which is not held.
  </Property>
  <Property name="The workspace team">
    Members and roles are held at workspace level, so everyone already in the
    workspace can reach the new Project according to their role.
  </Property>
</PropertyList>

## The sequence

For a first Project, setup is ten steps and each unlocks the next. Full detail is
in [Setting up a Project](/onboarding/sources); the short version is that the
Project needs evidence before it can have a strategy, a strategy before it can
have topics, and an allowance before it can generate anything at scale.

Whether an additional Project walks that sequence depends on the workspace.

| The Project you are creating | Where its plan step sits | Is its blog held? |
| --- | --- | --- |
| Your account's first, with a signup benefit on it | After the Strategy | No, live from creation |
| Your first in a new workspace, after your account already spent its one Free grant | Before setup | Yes, and it starts unpublished |
| A paid sibling beside a still active Free Project | Before setup. It stays on the plan step until a billable plan is on it | Yes, until setup completes |
| Another Project in a workspace already on a paid subscription | After the Strategy, exactly like a first Project | Yes, until setup completes |
| A Project in a workspace invoiced directly | Nowhere. The step shows an "invoiced directly" panel | No, live from creation |

<Callout variant="warning" title="A held blog is not a broken one">
  While a Project's blog is held, its address does not serve the blog publicly
  and publishing it by hand is refused with a message asking you to finish setup
  first. Completing setup releases it. Nothing is lost in the meantime, and the
  hold is not something you can be left stuck inside: it is cleared by the same
  step that finishes the Project.
</Callout>

## The signup benefit covers one Project

The signup benefit lands on your account's first Project and no other. A second
Project is a paid purchase, and it starts as one.

<Callout variant="note">
  This is not an upsell mechanism. Every usage meter in the product is scoped to
  a Project, so a single signup benefit spread across many Projects would
  multiply the allowance with no counter noticing. The same reasoning bounds the
  trial to one Project. See [the trial](/billing/trial).
</Callout>

## Adding a paid Project beside a Free one

There are two routes and they lead to different places, so it is worth being
deliberate about which one you are taking.

<Tabs>
  <Tab label="Convert the Free Project">
    Put a plan on the Project you already have. It keeps its content, its
    knowledge, its blog and its address, and its allowance becomes the plan's own
    from that moment. The Free grant is spent: that Project is a paid Project
    permanently, and no grant returns to your account afterwards. See
    [the Free grant](/billing/free-grant).
  </Tab>
  <Tab label="Create a paid sibling">
    Start a second Project and buy it. Your Free Project is untouched and stays
    Free, so you end up running one of each. The new one is paid from the
    beginning.
  </Tab>
</Tabs>

### What a paid sibling is like before it is paid for

It exists, and it can do almost nothing. Setup short circuits to the plan step,
and until a billable plan is on that exact Project it will not complete setup,
will not publish its blog, and will not start any work that costs money to run.
Each of those refusals says the same thing: choose this Project's paid plan
first.

<Callout variant="warning" title="A sibling is charged from the first day">
  There is no trial and no grace period on an additional Project. Your account's
  one signup benefit has already been issued, so the second Project is billed from
  the moment you buy it. Decide before you create it, not after.
</Callout>

### The Free Project stays out of the billing

It is not billed, it does not appear on the subscription, and it holds no
position in the multi Project discount ladder, so it neither earns a discount nor
deepens anyone else's. Positions are counted over priced Projects only. See
[discounts](/billing/discounts).