The First Solution That Comes to Mind Is Not Always the Most Effective
During testing of our workspace management feature, I found a path that left a user with zero workspaces. This wasn't supposed to be possible. By design, every user in Mantle Chat must always belong to at least one workspace. The feature had shipped a guard. And the invariant still broke.
One thing worth saying upfront: I wrote that guard. What I'm about to describe is my own mistake.
Here's what happened and some of the ways we thought about fixing it.
The Setup
Mantle Chat workspaces have three roles: owner, admin, and member. Only the owner can delete a workspace. And there is one hard rule: every user must always have at least one workspace.
The first guard we added felt obvious: before deletion, check whether this is the user's last workspace. If yes, block it. A single backend check. Write it, test it, ship it.
Worth pausing on that word: last. The check counted every workspace the user belonged to — owned and member alike. It felt thorough. We never asked whether membership and ownership were actually the same thing for the purpose of this rule.
The Gap
The guard did exactly what we wrote. The problem was what we didn't write.
Because the check counted all workspaces — not just owned ones — a user with two owned workspaces and one they were a member of could do this:
- Delete owned workspace #1 — two workspaces remain, check passes.
- Delete owned workspace #2 — one member workspace remains, check passes.
- Leave that workspace — no guard exists on the leave action.
- End up with zero workspaces.
The invariant is broken. Not through a bug in the guard, but through a gap in where it applied.
The underlying issue: we treated owned and member workspaces as equivalent. They aren't. A member workspace is borrowed — you can leave it, or be removed from it. An owned workspace is permanent. The rule "at least one workspace" should have meant "at least one you own."
Some Options
We sat down with the problem and came up with a few fixes in this order, which matters.
Option A — React after the fact. Auto-create a "Default Workspace" whenever a user ends up with none. Let the rule break, then restore it. This was the first idea.
Option B — Block the leave action. Prevent a member from leaving if it's their last workspace. Guard the exit instead of the deletion.
Option C — Fix the deletion guard. Change the check from "does the user have at least one workspace?" to "does the user own at least one workspace?" Block deletion if it would leave the user with zero owned workspaces.
Option D — Non-deletable personal workspace. Give every user one workspace on signup that cannot be deleted — only renamed. The invariant becomes structural rather than enforced at runtime. No guard needed because the forbidden state is unreachable by design. This was actually how Mantle Chat worked in the beginning.
Option E — Ownership transfer requirement. Before allowing deletion of the last owned workspace, require the user to either transfer ownership to another member or create a new workspace first. The deletion is blocked at the UX layer, not just the backend.
Why C — and when D or E make more sense
Option A treats the consequence, not the cause. You let the invariant break, then patch it. The logic now lives in three places — deletion, leave, and a background creation — each one a new surface for bugs.
Option B closes one door while another stays open. A user can still delete all their owned workspaces first, as long as they have member workspaces. You fix half the problem and ship the illusion of a solution.
Option C corrects the rule itself. The invariant was never "has at least one workspace" — it was "owns at least one workspace." Membership can end at any time. Ownership can't be taken away. One check, one place, the right definition.
Option D is where we started. Every new user got a default workspace they could rename but never delete. The broken state was structurally impossible. We eventually moved away from it — not because it was wrong, but because it was more restrictive than necessary. Users wanted the freedom to delete any workspace, and we didn't want a special-cased workspace type adding complexity to every place in the codebase that touches workspaces. The flexibility was worth the tradeoff. But that tradeoff is what created the gap.
Option E is appropriate when losing a workspace has real consequences — for example, when the workspace has members, billing attached, or shared data. Forcing an explicit transfer step protects against accidental deletion and keeps the user in control. For our case, Option C was sufficient. But as Mantle Chat grows toward larger team workflows, Option E is something we will likely revisit.
What This Is Really About
To be clear: this is not a critical bug. It requires a deliberate sequence of actions most users would never take. No data is lost, no one is locked out — the app just reaches a state it wasn't designed for. These bugs happen. They're worth fixing, and more importantly, worth writing tests for — because the next person who changes the leave or delete logic won't know this edge case exists unless a test tells them.
But what's interesting isn't the bug. It's which solution came to mind first and why.
Option A — auto-create — was immediate and unanimous. "User ends up with nothing? Give them something." It maps directly to the symptom. It's the kind of fast, pattern-matching response that Daniel Kahneman describes as System 1 in Thinking, Fast and Slow: we don't reach for the best solution, we reach for the most available one.
Option C appeared when we stopped asking "how do we fix this?" and started asking "Is the invariant correctly defined, and is it enforced everywhere it needs to be?" That shift — from reacting to tracing — is what Tom Chatfield calls deliberate reasoning in Critical Thinking. Not the opposite of intuition. Just a slower, different lens.
The first solution is worth writing down. It's not always worth building.
— Mantle Chat Team