# Feature parity, and what to build next

2026-08-06

Ernest's read is that Invision's product is more complete than ours. This is the
comparison written down, so the build order is a decision rather than a guess.

## 🚨 What this is made of

Their licence is revoked, so their source is not an input to anything here and
never has been. This note is written from the running product as a user, public
documentation and marketing, how other platforms solve the same jobs, and first
principles.

**Function is ours to match freely. Expression is not.** Every row below names a
*job* — "somewhere to put photographs", "a way to sell a subscription" — because
that is the part that is not anybody's property. Their interface, their icons,
their palette, their setting labels and their app names come nowhere near this.

One caveat worth stating plainly: my knowledge of their current app list has a
cutoff, and Ernest has used the product more recently than I have. Treat the
left-hand column as "the well-established surface", not as an audit.

## What Convoro has today

Eighteen modules, and the list is not short:

| | |
|---|---|
| forum | forums, topics, posts, prefixes, polls, merge/split |
| member | profiles, custom fields, points, ranks, badges, leaderboard |
| moderation | reports queue, mod log, bulk actions |
| messenger | multi-party private messages |
| notification | notifications, email preferences, outbox |
| search | FULLTEXT with filters |
| reaction | reactions and reputation |
| attachment | uploads, drag-and-drop, lightbox |
| appearance | themes, tokens, revisions, per-member choice |
| page | custom pages and blocks |
| menu | menu manager |
| widget | front-end widget arranging |
| api | REST API with scoped tokens |
| webhook | outbound webhooks |
| extension | packaging, installer, hooks |
| download | files, versions, catalogue, submissions |
| realtime | live replies, typing indicators |
| — | GDPR export, erasure, consent, retention |

That last row is worth noting: **we are ahead there.** Data export, account
erasure with tombstones, a consent record and retention pruning are built and
tested. It is unglamorous and it is the thing a European site will ask about
first.

## The gap

Ordered by how many sites actually use the thing, not by how big it is.

| Job | Them | Us | Size |
|---|---|---|---|
| **A door in from other software** | converters for the major platforms | — | large |
| **Member-run sub-communities** | core | — | large |
| **Events with a date and a guest list** | an app | — | medium |
| **Somewhere to put photographs** | an app | — | medium |
| **Sign in with an existing account** | OAuth/SSO handlers | — | medium |
| **Structured content types** | custom databases in their CMS | pages and blocks, no databases | large |
| **Selling things** | a commerce app | — | very large |
| **Personal journals** | an app | — | small |
| **Automatic promotion between groups** | rules | — | small |
| **Bulk email to a filtered audience** | built in | outbox only | small |

## The one that is not on their list

**The door in is the gap that matters most, and it is not a feature they have —
it is the reason nobody can leave anything for us.**

Every other row is something a site would enjoy having. This one is the
difference between a forum somebody can adopt and a forum somebody can only
start from nothing. A community with eleven years of posts does not evaluate our
Gallery; it asks whether its posts survive the move, and if the answer is "start
again" the evaluation is over.

It is also the cheapest to be good at, because the work is bounded and testable:
read somebody else's schema, write ours, keep the ids stable, redirect the old
URLs. Ernest has built importers before — the Flarum one handles ten sources —
so this is a known quantity rather than a research project.

Recommended first, and by a distance.

## Then: member-run sub-communities

Their version is included in the core product, so every site that runs it has
the feature and a meaningful number use it heavily. It is the one absence that
changes what a community *can be* rather than what it can display: a place where
members make their own spaces, with their own membership and their own
moderation, without an administrator creating a forum every time.

It is also the largest single piece of product design in this list, because it
touches permissions everywhere. Worth doing early for exactly that reason — the
permission model wants to learn about it before there are forty more screens
built on the assumption that it does not exist.

## Then: events, and photographs

Both are the same shape of work — a content type with its own listing, its own
permissions and its own view — and both are genuinely used. Events wins on
usefulness per line of code: a date, a place, a guest list and a reminder covers
most of why people ask for it.

Photographs are the more visible of the two and the more finicky: thumbnails,
EXIF stripping (a photograph carries the address it was taken at, and a forum
that publishes that by accident has done real harm), and a viewer that works on
a phone.

## Then: signing in with an existing account

Not a feature people ask for by name and one they notice immediately when it is
missing. It is also a migration lever: a site moving to us keeps its members'
existing sign-in if we support the same providers.

Small enough to slot between the larger pieces.

## Deliberately last: selling things

A commerce app is not one feature. It is a catalogue, a cart, tax, invoices,
subscriptions with renewals and dunning, refunds, and a support desk — and every
one of those is a place where being nearly right costs somebody real money.

Convoro is free software. Building a payments system into it means every site
that runs it inherits our mistakes about money. The honest version of this is a
much smaller thing done well — one-off and recurring payments against the
entitlement seam the Downloads module already has — and the rest left to the
people who do payments for a living.

That seam exists and is webhook-safe. It is waiting for a decision about a
provider, not for more code.

## Structured content types

Their CMS lets an administrator define a content type — fields, a listing, a
view — without writing code. It is powerful and it is the feature most likely to
be quietly load-bearing on a site that has one, which makes it a migration
blocker as well as a gap.

Large, and worth a note of its own before anything is built. Pages and blocks
already exist; the missing half is the data model.

## What this note does not recommend

**Matching their app list for its own sake.** Personal journals are on the list
because they exist, not because many sites use them. Building one to say we have
one is how a product becomes a list of features nobody opened.

**Matching their interface.** Said in the roadmap already and repeated here
because a parity document is exactly where the temptation lives: the screenshot
test is that ours placed beside theirs reads as a different product doing the
same job.

## Suggested order

1. **Importers** — the door in; nothing else matters if nobody can arrive
2. **Sub-communities** — early, because permissions should learn about it now
3. **Events** — most usefulness per line of code
4. **OAuth sign-in** — small, and a migration lever
5. **Photographs** — visible, finicky, worth doing properly
6. **Structured content types** — its own design note first
7. **Payments** — the small honest version, against the existing seam
8. Everything else, when somebody asks for it by name
