A simple project management tool for small teams: why fewer features is the point
A small team needs a list everyone will actually open, not a system to administer. Here is what we left out of fenbs, who it suits, and who it does not.
6 min read
The best project management tool for a small team is the one every person on it will open without being asked. That usually means one board, a handful of columns, a clear way to say who can do what, and nothing that needs an administrator. fenbs is built on that belief: four words to learn, four lanes, three kinds of task, and a deliberate refusal to add the features that turn a list into a system.
This piece explains the reasoning, lists plainly what fenbs does not do, and says who should pick something else.
Why small teams end up with tools they do not use
Large project management tools are built for large organisations, and they are good at what those organisations need: planning across many teams, reporting upwards, configuring a process for each department. Every one of those abilities arrives as a setting, a field or a screen. A team of five inherits all of it.
The result is familiar. One person becomes the keeper of the tool. Everybody else finds it slightly too much effort to file a small thing, so small things go into chat instead, and the board slowly stops being true. A board that is not true is worse than no board, because people still half trust it.
The fix is not a better-configured big tool. It is a tool with less in it.
What is in fenbs
Four words
- Board. Think of it as a whiteboard with everything you need to do and everything you have done. You get one, ready to write on.
- Task. One thing you need to do. A task is a Feature, an Enhancement or a Bug.
- Lane. The status of a task. Every task is in exactly one of four lanes: To Do, Next Up, In Progress, Completed.
- Member. Somebody who can see the board: a person, or an AI assistant working on a person’s behalf.
A name for every task
Each task gets a ref such as BU-046. The letters say what kind of thing it is and the number identifies it. Numbers are never reused, even after a delete, so “BU-046” said in a meeting, a commit message or a text to a client means the same task in two years. There is also a separate box on every task for your own reference: a job number, a ticket number, a client PO.
A few things that earn their place
- Priority from 1 to 10, where 1 is the most urgent, grouped into bands so you can filter by “high” without arguing about 2 versus 3.
- Optional projects and categories. Type a new name in the task editor and it exists; there is no list to set up first.
- A sort for each lane: Custom, Urgent, Newest, Oldest, Changed, A–Z or Number. To Do is triaged and Completed is a record, so they are read differently.
- Add many: paste a list, check the preview, and create them all together.
- History: every change recorded with who made it, and a trail on each task.
- Roles, so your client can look and comment while your team does the work.
What is not in fenbs, on purpose
fenbs has no epics, no sprints, no story points, no custom fields and no automations. The four lanes are fixed; you cannot add a fifth or rename them. There is no fourth kind of task.
These are not gaps on a roadmap. Every request to add one of them is a request to become a worse version of software that already exists. If you need sprints, tools built around sprints do them well. What fenbs can offer instead is a promise: the thing you learn in the first five minutes is the whole thing, and it will still be the whole thing next year.
The test we use
fenbs has to stay simple enough for a site foreman and precise enough for a software developer. If a feature would fail either half of that sentence, it does not go in.
The one place fenbs is not minimal
There is one area where fenbs does more than most simple tools, because it is the reason the product exists: who can do what. People and AI assistants are both members of a board, each limited by a role, and every change is signed by whoever made it.
For a small team this is practical rather than bureaucratic. Your client can read and comment and cannot move a card. A tester can file a bug and cannot rewrite your tasks. A crew can mark work done without being able to change what the job says, because moving a task between lanes is its own permission, separate from editing. When someone is refused, they are told exactly which permission they are missing. And if your team uses AI assistants, each one gets a token that can never do more than the person who issued it. The how it works page covers this in a few short sections.
Who fenbs suits
- A solo developer whose AI assistants do much of the typing, and who wants somewhere to put an idea the moment it arrives.
- A small product team whose client or testers find the bugs and should be able to file them directly.
- Someone who runs the work without writing the code, and needs a readable record of what each assistant actually did.
- A small trade or site team that needs a shared list a foreman will use from a phone.
- Anyone who has been keeping a backlog in a shared document and needs members and roles but not a platform.
Who should choose something else
Honesty here saves everybody time. fenbs is the wrong choice if you need any of the following.
- Sprint planning, velocity, burndown charts or story point estimates.
- Custom workflows with your own columns and statuses.
- Custom fields, forms or rule-based automations.
- Gantt charts, dependencies between tasks or resource planning.
- Portfolio reporting across many teams.
Plenty of established tools do those things well, and a team that needs them should use one. A team that does not need them should not have to carry them.
What it costs
Personal is $4.99 a month for one person’s own board. Teams is $99.50 a month for a shared workspace for your whole team, and it is one price however many people join; it is not charged per person. AI assistants cost nothing extra on either plan. If you stop paying, the board goes read-only, nothing is deleted, and you can still take everything out. The details are on the pricing page.
How to try it properly
Do not evaluate a simple tool with a demo project. Paste in the real list you are working from this week, using Add many. Add the one person who most often tells you about problems, with a small role. Work from the board for a week. At the end, ask one question: is the board still true? If it is, the tool is doing its job. If everybody drifted back to chat, no feature list would have saved it.