Simple Is Not the Same as Small
Fewer nouns isn't fewer capabilities. It's the same work, reached without learning a vocabulary first — and we did give something up to get there.
Someone on a sales call asked our founder a direct question: where are the custom fields. Not politely. He'd used three other tools before this one, and all three had custom fields, and he wanted to know what we were hiding.
We weren't hiding anything. We just didn't build it. That's a harder sentence to say out loud on a call than it looks on a page.
The objection is fair
If you count nouns, Team and Tricks looks thin. Organisation, project, task, document, chat, request, member, guest. No custom fields. No calendar view. No dependency graph. Someone who has run a PMO for a decade can list six things missing in under a minute, and every one of them is a real thing other tools have.
The easy answer is "we're simple." That answer is also lazy, and it dodges the actual question, which is: simple compared to what, and what did a team lose to get there.
So here's the honest version. Fewer concepts is not fewer capabilities. It is the same capability, reached without learning a vocabulary first.
What a status field actually hides
Take status. Most tools give you To Do, Doing, Done, and then a settings page where you can add more columns if three isn't enough. Teams add columns. Blocked. Waiting on Client. In Review. Needs QA. Each column is a small act of honesty — someone noticed that "Doing" wasn't telling the truth anymore.
We didn't add columns. We added attention markers on checklist rows — Question, Attention, Blocked — and progress reports on Classic tasks, where someone writes what's actually happening in a sentence instead of picking from a list that was never going to have enough options. The capability is still there. A blocked task is still visible as blocked. But nobody has to go into settings and invent a new status first, and nobody downstream has to learn what your custom "Waiting on Legal" column means versus mine.
Same work. No new noun. That's the whole trade, repeated across the product.
Two scenarios that look identical from outside
A three-person agency needs to track a client review step that sometimes stalls for two weeks. In a tool with custom fields, someone builds a field called "Review Stage" with four options, trains the other two people on what each option means, and six months later nobody remembers why option three exists.
In Team and Tricks, that review step is a checklist row with an Attention flag, or a Classic task with a progress report that says "waiting on client sign-off, pinged Tuesday." Anyone opening the task reads a sentence instead of decoding a dropdown someone else configured. The information made it through. Nobody had to build anything to carry it.
Second scenario: a founder wants to know if a task is a quick ask or owned work before anyone touches it. In a tool that only has tasks, every ask becomes a task — a ticket for "can you send me the login," sitting in the same list as "redesign the onboarding flow," with the same ceremony attached to both. We split that at the root: a task is something you own and will do, a request is something you need from someone else. That's not a feature flag. It's a different noun for a different kind of thing, because collapsing the two was costing people the ability to tell at a glance what actually needed doing by whom.
The thing we refused
Here's the concession, stated plainly: we will not build custom fields, and we will not build a dependency graph. Not "not yet." We looked at both and said no, on purpose, because each one buys a team the ability to configure a thing their coworkers then have to learn before they can read the board correctly.
A custom field is a small act of local meaning-making. It solves the problem for the person who built it. It creates a new problem for the next person, who has to ask what it means, or guess, or build their own competing field because nobody told them the first one existed. Multiply that across a team of fifteen for two years and you get a board that only the longest-tenured person can actually read.
We've decided that cost is bigger than the convenience. A team that needs a dependency graph to coordinate thirty interlocking workstreams might be right that they need one — and they should probably use a tool built for exactly that. We are not that tool. We are the tool for a team where nobody has the job of maintaining the vocabulary.
Where TAI fits the same argument
The clearest version of this trade shows up in TAI. We didn't build an automation builder — no rules to write, no triggers to configure, no "if status changes to X, do Y" logic for someone to maintain and later forget. Instead, TAI follows up on its own in three specific situations: a deadline close, a deadline missed, a task still sitting as a draft. That's not a smaller version of automation. It's the same outcome — someone gets reminded without a human doing the reminding — without anyone having to learn a rules syntax first.
TAI also doesn't get its own permission system. It uses the tools the buttons use, as you. That's another place we refused to add a concept — a separate AI permission matrix — because it would have meant teaching people two ways to think about who can do what, instead of one.
What this costs you, specifically
If your process genuinely needs a sixth status, a custom taxonomy per project, or a dependency chain visualised across forty tasks, we are telling you honestly that you will feel the ceiling here. That's not a hedge. It's the actual shape of the trade.
What you get back is a board that someone who joined last week can read without a tour. That's not a small thing, and it's not the same thing as small.
