Skip to content

FA onboarding guide

The single page a new Founder's Associate reads first. It assumes zero prior context about SCAILE, Claude Code, or the venture factory model. Work top to bottom. Don't open Claude Code for your first real task until every box in the Day 0 checklist is ticked.

This guide was rewritten after a real first project (the Kigentic build) surfaced gaps that cost days. The rules below are blunt on purpose — they are the things people got wrong, not theory.

Day 0 checklist

Do not write a line of code until all three blocks below are checked. If something is missing, your first job is to get it — request access on day 1, before anything else.

A. Accounts and access

Done Item Notes
☐ Bitwarden Password manager. Every credential and secret lives here — nothing personal, nothing in plaintext.
☐ Google Workspace (@scaile) Your company email and the login you use for Vercel, Supabase, and most tools.
☐ Slack Internal comms. Joined and on your phone.
☐ Claude plan A paid Claude plan that includes Claude Code — at SCAILE this is the company Team plan, not a personal Pro you pay for yourself. Confirm with your guide before paying for anything.
☐ Claude Code installed Installed, claude runs, you authenticated in the browser. See install steps.
☐ GitHub — scailetech org You can see the org's repos. Not your personal GitHub — the scailetech org.
☐ Vercel — scailetech team You can see the scailetech team in the team switcher.
☐ Supabase — scailetech org You can see the scailetech organization in the org switcher.
☐ Notion Venture builds and knowledge base.
☐ Granola Meeting transcription. On for every meeting.
☐ Linear + Twenty CRM Read access at minimum.
☐ MCPs configured Notion, Gmail, Drive, Slack, Granola connected to Claude Code — see the Claude Code page.

Who grants each of these: who-grants-what.md. If you don't have GitHub / Vercel / Supabase access under scailetech, stop and request it now — you cannot do the job without it and you must never substitute a personal account.

B. Briefing and scope — confirm with your guide before any code

Done Item
☐ Read the brief critically — as a pitch to interpret, not a spec to execute literally.
☐ Restated the core task in my own words and got a "yes, that's it" from my guide (Niccolo).
☐ Confirmed the venture name. The name in the brief is a working codename — I do not ship it as-is unless explicitly told to. I picked/proposed a real name and got it confirmed.
☐ Confirmed the target market and language, and flagged any language gap today (see the language rule).
☐ Confirmed first-MVP scope — what's in, what's explicitly out.
☐ Confirmed my operating line (guide / strategic owner / context input) and the working source of truth for this venture.
☐ Got an explicit "go build" from my guide.

C. Ground rules — acknowledge

Done Rule
☐ All infrastructure lives under scailetech — GitHub, Vercel, Supabase. Zero personal accounts, zero exceptions.
☐ Secrets live in Bitwarden and in the project's environment variables. Never committed to git, never pasted in Slack.
☐ No production deploys without sign-off. Preview deploys are yours; production is not.

When all three blocks are green, you're ready. The rest of this page explains the why behind each rule and the how of the day-to-day.

1. What SCAILE is (the 60-second version)

SCAILE is a Hamburg-based GEO (Generative Engine Optimization) and full-stack content engine startup. It wins attention inside AI-generated answers — the layer above traditional SEO — and it operates as a venture factory: one company, one upside. The team builds ventures (own and partnered) and runs content + GTM engines for clients, all on the same underlying playbook. Your one venture matters beyond itself because it feeds the engine everyone runs.

Full context: what-is-scaile.md and venture-factory-model.md.

2. What the FA is

You shadow one co-founder, take over his operating backbone, and hand him drafts instead of blank pages. You prepare; he cross-checks. You are not hired to set strategy — you're hired to remove everything that stops the founder from doing it. The recommended ramp is to own one venture end to end first; that's how you learn the business model and the engine.

Full context: what-is-the-fa.md, ownership-and-limits.md, venture-ownership.md.

3. Claude Code — what it is, and how to run it

Claude Code is Anthropic's agentic command-line tool. You run it in a terminal inside a project folder, describe what you want in plain English, and it reads your files, writes code, runs commands, and edits the repo — with you reviewing each step. At SCAILE it is the primary execution surface for all non-engineering work. The role is genuinely impossible without it, so getting fluent fast is part of week one, not optional.

Install it

Claude Code ships as a native installer — there is no npm install step, and you do not need Node.js for the tool itself.

irm https://claude.ai/install.ps1 | iex

curl -fsSL https://claude.ai/install.sh | bash

brew install --cask claude-code

Native installs auto-update. (Note: a venture's codebase will usually still need Node.js, Git, and other tooling — install those per the project's README. The line above is just for Claude Code itself.)

Start a session

cd path/to/your/project
claude

On first run it opens your browser to log in — sign in with the company Claude account, not a personal one. Credentials are stored locally; you won't be asked again. Inside a session, /login switches accounts.

Give it context

Claude Code reads the project files on its own. The one file that matters most is CLAUDE.md in the repo root: persistent instructions Claude loads at the start of every session (build commands, conventions, what to do and not do). To create one, run /init inside a session and let Claude draft it from the codebase, then edit. This playbook repo has its own CLAUDE.md — that's how the playbook answers questions about itself.

Must-know commands for your first week

Command What it does
claude Start an interactive session in the current folder
claude "add a contact form to the landing page" One-off task from the shell
claude -c Continue the most recent conversation here
/init Create or improve the repo's CLAUDE.md
/help List every command
/clear Clear the conversation when you switch tasks
/context See what's filling the context window
Shift+Tab Cycle permission modes (Default → auto-accept edits → plan mode)
Esc Stop Claude mid-turn

Deeper setup, MCPs, and shared prompts: claude-code-and-mcp.md. You can also query this playbook itself in Claude Code — see use-in-claude-code.md.

4. The briefing — read it critically before you build

A brief is a pitch to interpret, not a spec to execute literally. The single most expensive early mistake is taking the brief at face value and building the wrong thing. The Kigentic build is the cautionary example: the brief arrived as "Kigentic, an AI-expert marketplace," and the right move was not to build a marketplace called Kigentic — it was a demand-capture portal under a new name. (See worked-example-kigentic.md.)

Where the brief lives: there's no fixed location yet. It's usually forwarded by Niccolo, Sebastian, or Simon, and the real working source of truth is the venture's working sheet. If you can't find it, ask Niccolo where the brief and the working sheet are — that's question one, not a thing to guess.

Questions to always ask before you start — get answers, then restate them back and wait for confirmation:

  1. What is the actual core task? Reframe the brief in your own words. ("So we're capturing SME automation demand, not building marketplace software — right?")
  2. Is the name final, or do I choose one? Treat the brief's name as a working codename. Default expectation: pick a new, real venture name and confirm it. Don't ship the codename by accident.
  3. What's the target market and language? And do I have the language skills to build and judge content for it? (See §5 — this is a blocker, not a detail.)
  4. What's in scope for the first MVP, and what's explicitly out?
  5. Who's my operating line for this build — primary guide, strategic owner, context input?
  6. Where is the working source of truth (sheet, Notion, repo)?
  7. What does "done" look like for the first milestone?

Then hand your guide a 3–5 line restatement: here's the task as I understand it, here's the name I propose, here's the first-MVP scope, here's what I'm starting on. Get a "yes" before you build. This costs ten minutes and saves days.

5. The language rule (non-negotiable)

Confirm the target-market language during briefing, and flag any gap immediately — day 0 or day 1, never day 3.

It makes no sense to build a German-targeted venture if you don't speak German. You cannot write or judge high-intent content, landing pages, or GEO copy in a language you don't read. If the venture targets a market whose language you don't have (German for DACH is the common case), say so the moment you spot it. It is a blocker, and surfacing it late is far worse than surfacing it early.

Resolution is your guide's call, not yours to paper over — typical options: pair with a native speaker, run translation with native review, or re-scope the venture. What you must not do is quietly produce content you can't evaluate.

For DACH/German ventures this also drives infra choices — host data in the EU (see §7).

6. Naming and conventions

There's no carved-in-stone naming standard yet (lock these with August, who owns the scailetech GitHub org — see the ideas log). Until then, use these sensible defaults and keep everything consistent across services:

  • Venture name — chosen with the team, not inherited from the brief codename. Short, brandable, and the same everywhere.
  • Slug — one kebab-case slug derived from the venture name (e.g. acme-portal). Reuse it for the repo, the Vercel project, and the Supabase project so they line up.
  • GitHub repo — scailetech/<slug>, private by default.
  • Vercel project — <slug>, under the scailetech team.
  • Supabase project — <slug> (or <slug>-prod / <slug>-dev if you split environments), under the scailetech org.
  • Domain — confirm with Simon/Niccolo before buying, and buy it through the central/team account, never a personal card. Don't register a domain on a whim.

7. Tech stack and infrastructure — the scailetech rule

Hard rule, zero exceptions: every venture's infrastructure lives under the scailetech organization — on GitHub, Vercel, and Supabase. No personal accounts, no "I'll move it later." A project created under a personal scope is misaligned infrastructure that someone has to migrate, and it broke things on the first build.

If you don't yet have access to scailetech on any of these, request it on day 1 before you write any code (see the Day 0 checklist).

The full step-by-step for creating a Vercel project and creating a Supabase project under scailetech — including secret handling and the EU region choice for DACH ventures — lives on the infra page: vercel-render-supabase.md. Do the setup from there; don't improvise it.

Two lines worth repeating from that page:

  • Secrets (Supabase keys, DB passwords, API keys) go in Bitwarden and in the project's environment variables — never in git.
  • Render is back-end/API hosting and is engineering's surface — you read it for context, you don't deploy to it by default.

8. The daily workflow

The atomic motion (the core loop) is: Shadow → Convert → Cross-check → Execute. For venture build work specifically, a day looks like:

  1. Pick the task from the working source of truth (sheet / Notion / Linear). One concrete outcome at a time.
  2. Open the repo and run claude. Describe the task in plain language. For anything non-trivial, ask it to propose a plan first (Shift+Tab → plan mode) and read the plan before it edits.
  3. Review every change. Claude asks before editing files — read the diffs. You own what gets committed.
  4. Commit in small, sensible steps with clear messages. You can ask Claude to commit for you, but read what it's committing. Push to a branch / preview; never push to production without sign-off.
  5. Close the loop — update the working source of truth so the founder cross-checks a finished draft, not a blank page.
  6. Log friction and ideas as you go — the moment you hit a gap or have an idea, drop a row in the ideas log (in Claude Code: "log this idea: …").

When to ask for help (don't burn a day stuck):

  • Blocked for more than ~30 minutes on the same wall.
  • Anything irreversible or production-facing (deploys, deleting data, sending external email, buying a domain).
  • The scope or the task itself feels unclear — re-confirm with your guide rather than guessing.
  • Anything touching engineering's surface — clear it with Niccolo first; don't ping engineers directly. See when-to-involve-engineering.md and escalation.md.

9. Self-verify before your first task

Re-read the Day 0 checklist. Concretely, you should be able to answer yes to all of:

  • I can log in to GitHub, Vercel, and Supabase and I can see the scailetech org/team in each.
  • claude runs in my terminal and I've authenticated with the company account.
  • I can state the venture's core task in one sentence, and my guide agreed with it.
  • I know the venture's real name (not just the codename) and it's confirmed.
  • I know the target market and language, and I've flagged any language gap.
  • I know what's in and out of the first MVP.
  • I know my operating line and the working source of truth.
  • I have an explicit "go build."

If any answer is "no," that's your first task — not code.

Your operating line

  • Primary guide / first contact: Niccolo.
  • Strategic owner: Simon (the founder you shadow).
  • Venture / context input: Sebastian and/or Anton, depending on the project.
  • Engineering: hands-off — clear anything through Niccolo first.

Names and contacts: who-is-who.md.

Owner: Current FA Last reviewed: 2026-06-14