Understand Atelier

Atelier is a SaaS application supplied with editable sources, tests and operating tools. Its team workspace connects accounts, projects and subscriptions. You can adapt it to your product or replace its project workflow while retaining the foundation you need.

Choose your next task

What Atelier lets users do

An account is a person's identity; a team is the shared workspace. Creating an account also creates a team owned by that account. Invitations let the same account join other teams, and the Team selector changes the workspace being viewed. A person's role belongs to each team: owning one does not grant ownership of another.

These permissions are checked on the server. Hiding a button is only the interface representation of that policy.

Accounts and invitations

Users create an account with an email, a password of 12–128 characters and a team name. They verify the email before signing in. Resend verification email and Forgot password? provide recovery links; completing a password reset signs the account out everywhere.

OAuth sign-in and single sign-on (SSO) are not configured in the supplied application.

To try collaboration locally after creating your first project:

1. As the owner, enter a new fictional address such as sam@demo.test under Team, then choose Invite member.
2. Open the local mailbox and the invitation for that recipient. If the recipient is new, create their account and verify their email first.
3. Sign in as that recipient, reopen the invitation and choose Accept invitation within 48 hours. The signed-in address must match the invited address.
4. Select the invited team in Team. Its projects are readable; project creation, archiving and billing controls are unavailable to this member.

The owner can cancel a pending invitation or remove a member after confirmation. Removal revokes access to that team; it does not delete the person's account or their other teams. Account closure and eligible erasure are separate operator tasks, not member removal.

Projects and quotas

Projects have a name of 1–120 characters and an optional description of up to 2,000 characters. The supplied workflow creates, lists and archives projects. It does not include project editing, unarchiving, tasks, attachments or a project-detail workspace; add those only if your product needs them.

The local demo allows three active projects per team. Archived projects remain visible and stop counting toward the quota. Archive frees a slot without deleting the project. Both creation and archiving require the owner and an active plan, including when the team is already over its quota. Concurrent creation requests share the same enforced limit.

Without an active plan, existing projects remain readable to team members, but creation and archiving are unavailable. Canceling the demo subscription is a useful way to inspect this state.

Subscriptions

The default mode uses Activate subscription and Cancel subscription to simulate access changes locally. No card or Stripe account is involved. Email is captured in the local mailbox, using fictional .test addresses.

A public installation uses configured Stripe offers. Each offer has an active project quota; the owner subscribes through Checkout and uses Manage billing to open the Stripe portal. The portal shows the available changes, timing and cost. Resume checkout returns to an unfinished checkout, and Refresh subscription status asks the application to synchronize its billing state.

A return from Checkout is not itself proof of an active subscription. Project writes depend on the subscription confirmed in the application. Its billing period must have started and not expired. Changing the configured Stripe account, price, quota or portal can also block writes for existing subscribers. A cancellation scheduled for period end retains access while that subscription remains active within its current period. Once the period expires, new project writes require a confirmed renewal. The supplied policy requires Stripe status active; it does not grant project writes for a trial or overdue subscription.

Use configuration and hosting for the transition to real integrations. Public staging uses Stripe test payments; live billing can charge real customers.

Decide what your product adds

The foundation already connects identity, team access, a paid-write policy, persistent data, email and billing work. Your product still needs its own useful workflow and the rules that make that workflow correct. For example, turning projects into client engagements may require editable details, delivery dates and new roles.

Make those decisions before modifying permissions or pricing. Define who may perform each action, which resource a quota counts, what happens when a plan ends, and how shared records behave when a person leaves. Then follow the customization workflow to implement and verify the complete path.

Operating a public service also requires your own hosting and provider accounts, customer-facing terms and privacy information, and a process for support and data requests.