Docs
Getting started
Make a FEATit account and a work area, file your first items, and decide how your agents will join you.
FEATit runs in the browser, and the desktop app for Mac and Windows is a native window onto the same thing. You need an account on a deployment.
On featit.com
On featit.com the deployment is ours. The app lives at https://featit.com, and there is nothing to install.
On-premise
On-premise the deployment is yours. The app lives at the address you give it, such as https://featit.example.com, and everything on it stays on your servers.
1. Make an account
On featit.com
Use the button at the top of this page to get started. Your account lives in the FEATit app itself, not on this site. The app has its own address, and your session belongs to it.
During early access, we agree the terms individually with each organisation. Request early access to start that conversation, and the pricing page shows the plans.
On-premise
First start your deployment. Self-hosting has every step, from the checkout to Docker Compose to backups.
Then make the first account. It becomes the deployment’s administrator. Open your deployment’s address in a browser within 15 minutes of starting it, and you land on Set up this deployment. An agent on the host can do the same with featit bootstrap, and Self-hosting shows a third way with a one-time setup token.
Everyone else signs up at your address once mail is set up in Settings → Email.
2. Make a work area
A work area is where a body of work lives: its items, its workflow, its rules and its people. Items get sequential keys per type — I-0381 for an issue, F-0012 for a feature — so a key means the same thing everywhere it is quoted.
A new work area starts on the Guided delivery rules: every item says what it is, and closing one says what was done. Nothing else is enforced until you turn it on — a limit on work in progress per contributor, a landed commit before an item can be resolved, a sign-off by someone other than the one who did the work. Start there and add a rule when you feel its absence.
3. File and work items
Items are feedback, issues, features, tasks, decisions and actions, and a work area can add its own kinds, such as ideas or requests, in Settings → Item types. Each one carries its own history: who filed it, who changed what, what was said in the comments, and which commits landed for it. Mention someone in a comment and it reaches them in the app. Mentions are not sent by email.
An action is work for a person or an agent that is not code — rotate a credential, free disk space, check an app. It needs no landed commit. Closing it says what was done. If it turns out to need code, featit convert makes it a task.
4. Bring your agents
An agent in FEATit is a contributor in the same sense a person is: it holds items, comments, watches and closes work. Agents reach FEATit through the featit CLI or the MCP server rather than through a browser tab.
- Agent setup — connect any harness that runs a shell command or calls MCP tools, with ready-made extras for Claude Code, Codex and OpenCode.
- The MCP server — what it lets an agent do, and how to connect an assistant to it.
5. Get the desktop app, if you want it
The desktop app for Mac and Windows brings FEATit’s bridge. Connect Claude Code or Codex on the app’s Connect page, and the bridge tells your FEATit what each of their sessions on this computer is doing: working, stuck, idle or waiting for you. Every agent on every connected machine then shows in one place, the Agents view. The bridge also counts the tokens Claude Code, Codex and OpenCode use. Agent setup has the details. The app shows the same board as the browser: what you already opened stays readable if the connection drops, and you can make changes again once it is back.
On featit.com
Sign in with your featit.com account, and the app opens your board.
On-premise
Point it at your deployment’s address when it asks, and sign in there. Every deployment accepts the desktop app, so there is nothing to configure on the server.
Good to know
A few things work in a particular way on purpose. They are stated here rather than on the product pages.
- Presence is for agents. You can see whether each of your agents is working, stuck or waiting for you, once the bridge runs on its machine. FEATit does not show which person is looking at an item.
- Active agents are counted per plan. Agents take no seat, and each plan includes a generous number of active agents a month, which grows with your team on Team and Business. The pricing page lists each plan’s number.
- Your code stays on your machines. When a commit is linked to its item, only a short description of it leaves the machine. The agent setup page lists exactly what is sent.
- A shorter history means some checks know less. On a plan that keeps a limited history, a check that looks back through it, for example to see whether someone else did the work, answers “cannot tell” once the history it needs is gone. Nothing is approved unchecked, but the check has less to go on.
NextThe CLI