Designing a Comparison Schema When Features Aren't 1:1

Theo Brenner — Sat, 25 Jul 2026 08:08:17 +0000

I spent an embarrassing amount of time building comparison tables before admitting the data model was wrong. Not the UI — the schema underneath. Every "Tool A vs Tool B" page starts from an assumption that quietly poisons everything downstream: that both tools have the same features, and you just need to check boxes.

They don't. That is usually the entire reason one exists.

The false equivalence problem is a schema problem

The default schema is a matrix. Rows are features, columns are tools, cells are booleans.

-- the version that ruins your dataset
CREATE TABLE comparison (
  feature_id TEXT,
  tool_id    TEXT,
  supported  BOOLEAN
);

The failure is that supported = false is doing at least five distinct jobs: the tool genuinely lacks this; the tool solves the same problem a completely different way so the feature name doesn't apply; it exists but only on a higher tier; it exists via a plugin rather than natively; or nobody checked.

Rendering all five as a red ✗ is not a display bug you can fix in the template — the information was destroyed at write time. And the second case is where comparison sites do the most damage. Scoring a git-backed CLI tool as "✗ real-time collaborative editing" is technically true and completely misleading; the tool's answer to collaboration is branches and review, which is a different shape, not an absence.

So the first schema change is: the cell is not a boolean.

CREATE TABLE tool_capability (
  tool_id       TEXT NOT NULL,
  capability_id TEXT NOT NULL,
  status        TEXT NOT NULL,   -- see enum below
  tier_required TEXT,            -- 'free' | 'pro' | 'enterprise' | NULL
  via           TEXT,            -- 'native' | 'plugin' | 'integration' | 'api'
  note          TEXT,            -- required when status = 'different_model'
  evidence_url  TEXT NOT NULL,
  verified_at   DATE NOT NULL,
  PRIMARY KEY (tool_id, capability_id)
);

with

status ∈ {
  full,              -- does the thing, no meaningful caveat
  partial,           -- does some of it; note explains the boundary
  different_model,   -- solves the problem, different concept; note REQUIRED
  not_applicable,    -- the concept does not exist in this tool's world
  absent,            -- genuine gap
  unknown            -- not verified; render as "—", never as ✗
}

different_model and not_applicable are the two that make the dataset honest. unknown is the one that keeps you honest — most comparison content is quietly full of unverified guesses rendered with the same confidence as tested facts. If your schema has no way to say "I don't know," your writers will say "no."

Capabilities are not features

The second fix is renaming the row axis, which sounds cosmetic and isn't.

Features are vendor vocabulary. One tool calls it Workspaces, another Projects, a third Teams, and a fourth has no such object because permissions attach directly to resources. If your rows are feature names, you have adopted one vendor's ontology as the neutral standard — usually the market leader's, which structurally flatters it and makes everyone else look incomplete.

Model rows as user jobs instead:

capability: "restrict access to a subset of content per group of people"
   tool_a: full             (Workspaces + roles)
   tool_b: different_model  (per-resource ACLs, no container object)
   tool_c: partial          (all-or-nothing sharing, no groups)
   tool_d: full             tier_required = 'enterprise'

Now different_model is expressible without being a demerit, and the note carries the actual decision-relevant information: tool_b can do this but you will configure it per resource, which is fine for 20 documents and miserable for 2,000.

Give capabilities their own metadata too, including an objectivity field — verifiable | contextual | taste. That column stops you from summing incomparable things. "Exports to CSV" is verifiable. "Feels fast" is taste. A single composite score that averages both is a number with no meaning, and it is the thing readers trust most.

Pricing is a model, not a number

Pricing deserves its own table because "$20/mo" is almost never comparable across two tools. The dimensions that actually differ:

Unit of charge: seat, workspace, usage, flat, hybrid
Free tier shape: perpetual-limited vs. time-limited trial vs. none
The cliff: which specific feature forces the upgrade (SSO, audit logs, API access — this is where the real cost hides)
Scaling behavior: cost at 1, 5, 20, 100 seats is a curve, not a point

So store unit, base_cents, per_unit_cents, included_units, and captured_at — the model, not the headline number. Then you can render honest scenario costs ("at 12 seats") instead of a headline price that only applies to a solo user on annual billing. Every pricing row needs captured_at because pricing rots faster than anything else in the dataset, and a stale price presented confidently is the fastest way to lose a reader permanently.

Provenance, or you are just writing opinions

Two constraints I would now enforce at the database level rather than in review:

Every claim carries evidence and a date. evidence_url and verified_at are NOT NULL. A claim older than your staleness threshold degrades to unknown automatically rather than sitting there looking authoritative. This is the difference between a dataset and a blog post.

Comparisons are derived, never authored. A "A vs B" page is a query over tool_capability, not a hand-written row. Hand-written comparison rows drift out of sync with the tool pages within weeks and you will never notice. Making it derived means one write updates every page that references it, and it makes an entire class of contradiction impossible.

Working through this on stackalt — where each entry has to say something real about pricing model, migration friction, and where a tool simply has no equivalent concept — the different_model status ended up being the most-used non-full value by a wide margin. Which is the finding, really: most tools that survive in the same category are not worse versions of each other. They disagree about what the problem is, and a boolean matrix has no vocabulary for disagreement.

Migration Friction Is the Real Cost of Switching Tools

Theo Brenner — Fri, 24 Jul 2026 19:00:23 +0000

Tool comparison posts obsess over feature matrices and monthly pricing. Both are the easy numbers. The expensive number is what it costs to leave, and almost nobody publishes it.

Three kinds of lock-in, in ascending order of pain

Data lock-in is the one people check. Can you export? In what format? A CSV dump that loses your relationship structure is not really an export.

Workflow lock-in is worse and less visible. Your team learned the tool's mental model. Your runbooks reference its UI. Your onboarding docs have screenshots. Switching means rewriting all of that, and none of it shows up in a pricing comparison.

Integration lock-in is the killer. Every webhook, every CI step, every Zap pointing at this tool is a thing that breaks on migration day. The count grows silently — nobody tracks how many integrations a tool accumulates until they try to remove it.

A rough way to score it before you commit

Before adopting anything, ask four questions and write the answers down:

Export fidelity — can I get my data out in a form a competitor can actually ingest? Not "is there an export button."
Integration surface — how many other systems will end up pointing at this? Each one is future migration work.
Config as code? — if the configuration lives in a database behind a UI, migration means clicking. If it lives in YAML in my repo, migration means editing files.
Who owns the identity? — if the tool is also your auth provider, leaving is a much bigger project than swapping a dependency.

Score each 1-5. A tool scoring badly on 3 and 4 needs to be substantially better to justify adoption, not marginally better.

Why the cheap option often is not

The pattern I keep seeing: a team picks the cheaper tool, accumulates 20 integrations over 18 months, then discovers the migration cost exceeds three years of the price difference they were optimising for.

Pricing is a recurring cost you can forecast. Migration friction is a one-time cost you cannot, and it lands at the worst possible moment — usually when the tool has already become a problem.

I write up alternatives with this lens — pricing model, migration friction, and the trade-offs that actually bite — at StackAlt.

The honest caveat

Sometimes lock-in is worth it. A deeply integrated tool that fits your workflow can be worth more than a portable one that does not. The argument is not "avoid lock-in" — it is "price it before you sign up," because the default is to not price it at all.

DEV Community: Theo Brenner