> ## Documentation Index
> Fetch the complete documentation index at: https://docs.featherframework.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Build a Kanban app

> Six parts, each one a scaffold command, a prompt, and a test. You end up with a multi-tenant SaaS on your own domain.

This series builds one application across six parts. Each part follows the same three
steps: scaffold a project, paste a prompt, then check what came back.

A scaffolded project has a fixed layout. Models, services and routes each have one home,
and a file placed there is registered without any wiring. Every project also carries a
`CLAUDE.md` describing the conventions, and `feather check` enforces the ones that can be
enforced.

Those two properties are what the middle step depends on. An assistant writing a feature
has somewhere to put each file and a rule set to follow, and you have a command that
reports whether it followed them. You will be reading results and running checks here
rather than typing out models.

<CardGroup cols={2}>
  <Card title="1. Static board UI" icon="layout-template" href="/tutorials/static-board-ui">
    A styled board with columns and cards. No database yet.
  </Card>

  <Card title="2. Persistent boards" icon="database" href="/tutorials/persistent-boards">
    It saves. Create and delete without a page reload.
  </Card>

  <Card title="3. Drag and drop" icon="move" href="/tutorials/drag-and-drop">
    Move cards between columns, and have it stick.
  </Card>

  <Card title="4. Personal Kanban" icon="user" href="/tutorials/personal-kanban">
    Sign in with Google. Roles, attachments, PDF export.
  </Card>

  <Card title="5. SaaS Kanban" icon="building-2" href="/tutorials/saas-kanban">
    One app, many companies, no data leaking between them.
  </Card>

  <Card title="6. Deploying" icon="ship" href="/tutorials/deploying">
    Your domain, real HTTPS, backups, deploy on push.
  </Card>
</CardGroup>

## How each part works

<Steps>
  <Step title="Scaffold" icon="folder-plus">
    Run `feather new` and answer a handful of prompts. Each part lists the answers that
    matter and why. Do this step by hand, because the answers decide what gets generated.
  </Step>

  <Step title="Run the prompt" icon="clipboard">
    Copy the prompt from the page and give it to your assistant from inside the project
    directory. It reads the tutorial, follows the conventions in `CLAUDE.md`, and runs
    `feather check` when it's done.
  </Step>

  <Step title="Test" icon="circle-check">
    Every part ends with a short list of things to click and one command to run. If the
    list passes, move on.
  </Step>
</Steps>

<Tip>
  Claude Code from inside the project directory is the smoothest path. It reads your
  `CLAUDE.md`, runs `feather check` and `feather dev` itself, and can act on the errors
  without you relaying them.
</Tip>

## Scaffolding answers by part

Parts 1 through 3 build on each other. Parts 4 and 5 each want a fresh project, because
they change the app type.

| Part | App type                         | Database   | Auth | Jobs    | Cache | Storage   |
| ---- | -------------------------------- | ---------- | ---- | ------- | ----- | --------- |
| 1    | simple                           | none       | no   | default | no    | no        |
| 2    | simple                           | sqlite     | no   | default | no    | no        |
| 3    | continues from part 2            |            |      |         |       |           |
| 4    | single-tenant                    | postgresql | yes  | default | no    | yes (GCS) |
| 5    | multi-tenant                     | postgresql | yes  | default | no    | yes (GCS) |
| 6    | deploys the app from part 4 or 5 |            |      |         |       |           |

<Warning>
  Redis caching defaults to yes in the prompts. Answer **n** for parts 4 and 5. Nothing in
  the series uses the cache, and saying yes makes the app expect a Redis server that isn't
  running. Background jobs can stay at the default, since the thread backend runs
  in-process.
</Warning>

## What you'll need

<Tabs>
  <Tab title="Parts 1 to 3">
    * Python 3.11+ and Node.js 22+
    * The Feather CLI
    * No database for part 1, SQLite from part 2 on
  </Tab>

  <Tab title="Parts 4 and 5">
    * PostgreSQL running locally
    * Google OAuth credentials, a client ID and secret
    * A Google Cloud Storage bucket and a service account JSON key
  </Tab>

  <Tab title="Part 6">
    * A working app from part 4 or 5
    * A domain whose DNS you control
    * A VPS you can SSH into as root. Two vCPU and 4 GB is enough to start
  </Tab>
</Tabs>

## Reading the code that comes back

You're not meant to accept it blind. Three commands tell you whether what you got is
sound, and they're the same three the prompts ask the assistant to run:

| Command                             | Answers                                                         |
| ----------------------------------- | --------------------------------------------------------------- |
| [`feather check`](/tooling/check)   | Were the conventions followed? Reports a file, a line and a fix |
| [`feather routes`](/reference/cli)  | What actually got registered?                                   |
| [`feather test`](/testing/overview) | Does it still work?                                             |

Each part also ends with a **What the framework did** section explaining the pieces worth
understanding, with links into the reference docs.

<Note>
  The full written tutorials, with every code block, are in the
  [Feather repository](https://github.com/RolandFlyBoy/Feather/tree/main/tutorials). The
  prompts point your assistant at them. Read them yourself if you'd rather build a part by
  hand.
</Note>