Your tracker was built for 200 people

By Darko Bačić, founder of App Tube · 9 October 2026

A tracker built for 200 people asks a team of four to do its paperwork. The paperwork is not the work. It is the setup, fields, views and reports that let a big company see itself. A small team pays for all of it and uses little of it. We make devBoard, so this is our view.

It is one of the few opinion pieces on our blog.

Big tools are built for the people who read reports

A big company buys a tracker for its managers as much as for its developers. Someone needs to see forty groups of people at once. Someone needs to prove who changed what, and when.

So the tool grows. It gets custom fields, a workflow for each group, permission rules, dashboards and reports across projects. Each of these answers a real question for someone near the top.

That is fine for them. The trouble starts when a team of four uses the same tool. They get every answer, and nobody is asking the questions.

Setup is the first bill

Before a big tracker shows its first card, someone has to set it up. They pick the types of work, the statuses and the required fields. They decide who may move a card to Done.

Each choice is small. Together they take a day, and someone has to keep them working. In a team of four, that someone is also writing code. The tool has hired a part-time admin without asking.

Then come fields and views

The new-task form in a big tracker often has a dozen fields. A small team fills in three: title, owner and due date. The rest sit empty. Or worse, they get filled with guesses so the form will save.

Views work the same way. There is a list, a board, a calendar, a timeline and a chart. Each one needs dates and links kept right, or it shows nonsense. A team of four looks at the board. The other views go stale without anyone noticing.

Then automations and reports nobody reads

Automations sound like saved time. "When a card moves to Review, assign it to Mira." Then someone renames a column, and the rule breaks without a sound. Someone else loses an hour finding out why.

Reports are the last cost. Charts of work done per week are made for a manager who is not in the room. In a team of four, the manager is in the room. She is also the one who would have to keep the data clean enough to chart.

What a small team can cut

Here is what we think a small team should keep:

• A board with three to five columns.
• Tasks with an owner and a due date.
• A way to group work into the next release.
• A timer, if you bill by the hour.

And here is what it can cut:

• Every field you have never filtered on.
• Every view except the board and a list.
• Automations you would not miss for a week.
• Reports nobody opened last month.

For the board itself, kanban for a team of three shows a setup that needs no meetings.

Where this argument is wrong

Some small teams need a big tool. If you work inside a large company, your tracker is chosen for you, and it has to talk to everyone else's. If a client wants custom reports and a full record of changes, you need the fields. If you will be forty people next year, moving later costs more than setting up now.

And some teams run a big tool lightly and are happy. A tool is only as heavy as you make it. If your team leaves most of it switched off, the size of the tool barely matters.

What we did about it

We built devBoard for the team of four, not for the 200. It has three levels of work. An epic is a big piece of work split into tasks, and a subtask is a step inside a task. It has releases, which group work that ships together, and tags (labels). It has no custom fields, no automations, no sprints, no Gantt charts and no docs. A new project starts with three columns, and boards in devBoard shows the rest. There is nothing to set up before your first card. Planning a release is the closest thing to a process we ask for.

That means devBoard is too small for some teams. The alternatives pages list other tools by need. We also wrote about why devBoard has no web version, which is the same choice in another place.