Public roadmap

What we're building,
and when.

What's built, what's being built, and what we've only argued about so far. Done items stay on the page so you can check the work. There are no dates on anything, because this is one person's spare time and a date would be a guess.

Done
In progress
Planned
Later: exploring
Tournament bracket engine
Planned
Single elimination, double elimination, and round-robin formats. Bracket progression, bye handling, and seeding, all via API.
tournamentsbrackets
Leaderboard and rating history API
Planned
Store and query per-player rating history, peak rating, and global or game-scoped leaderboards, without managing your own database tables.
leaderboardsrating history
Game engine SDKs
In progress
The Unity SDK has shipped: client, editor setup and a .unitypackage, plus runnable demos that hand a formed match off to Mirror, Photon PUN 2 or Fish-Networking, whichever you already use. Godot and Unreal are still to come. The REST + SSE API works from any engine or backend today.
UnityMirrorPhotonFish-Net
Webhook delivery for match events
Planned
Push match lifecycle events to your server endpoint as an alternative to the SSE stream, with retry logic and a delivery log in the dashboard.
webhooksserver-side
Next: after soft launch
Billing and paid plans
Planned
Subscription management and paid plans with higher usage quotas. MatchKit is free today, and the free tier already enforces its call caps — 30,000 writes a month, 1,000 a day; paid plans drop them for a monthly-active-player allowance instead.
billingquotas
GDPR data erasure and admin tooling
Planned
Self-serve player data erasure plus admin-side account management (role changes, deactivation, and deletion) for compliant operation in the EU.
GDPRadmin
Party and group matchmaking
Planned
Form a party and enter a queue together. Skill rating is aggregated across the party, with partial fills and party-vs-party balancing.
partiesgroups
Co-op and PvE matchmaking
In progress
A match that is one team against the game, not two teams against each other: a real single-team match shape, not a co-op run bolted onto an empty second team. The shape works now. A one-team match forms and ends on completed or failed rather than a winner, no rating moves because there is no opponent to move it against, and a player who drops out is reported with the rest so the run still closes. The queue setting that picks the shape isn't public yet, so every queue you create today is still two teams. Composition forming comes next: declare per queue which roles a run needs and how many of each, let players queue with ordered role preferences, and the solver covers the roles instead of handing your mission four snipers. Roles are strings you define; MatchKit ships no class list of its own.
co-opPvEroles
shape and outcome reporting done, role coverage next
Reliability rating
Planned
A rating axis that isn't skill: does this player finish the run? Built from completion and extraction rate, abandons and disconnects, and pro-social signals like revives and assists, all reported by your server when a run ends. The end-of-match call already takes a per-player field for whether that player was still there at the end, so the raw record exists; the score derived from it doesn't yet. New players start at a neutral prior rather than being punished for having no history, and it feeds the solver as a preference (grouping comparable reliability) rather than as a gate that locks anyone out. It won't touch win/loss.
co-opreliability
Power banding
Planned
Progression isn't skill, and in co-op the gap hurts both ends: a fresh player among maxed characters is dead weight, and the maxed player is bored. Give the player one opaque power number you define (gear score, character level, mission tier) and a per-queue band width, and the matcher only groups within the band. The band widens as players wait, reusing the same relaxation and wait-cap machinery the skill window already uses, so there's no second timer to reason about.
co-opprogression
Multi-region support
Planned
Region-aware queues so players match against nearby opponents. Today MatchKit runs as a single deployment.
regionslatency
Self-hosted distribution
Planned
The full stack (API, dashboard, Postgres, Redis) as a Docker Compose bundle on your own infrastructure, unlocked by a license file verified offline so nothing phones home. The compose stack is what we run ourselves today; what's missing before anyone else can run it is the license check and a versioned bundle to hand you. Until then, MatchKit is the hosted service.
Dockerself-hostedlicensing
Now: pre-launch hardening
Usage metrics in the dashboard
In progress
Your daily API-call usage is now read live from the server that enforces it, so the number on the billing page is the real one. Still to come: the Overview charts (request volume and matchmaking activity over time), which are the last part of the dashboard showing sample data rather than yours.
dashboardmetrics
Done
The fairness gate: LP refuses lopsided matches
Done
In LP mode, now the default, the solver won't ship a split whose imbalance exceeds the queue's match-quality tolerance. It forms nothing and leaves the players queued for a fairer match. Take one player at 3500 and nine at 1700: every arrangement is lopsided, so the gate holds it. The tolerance is per-queue, so you set how strict fair is; and a wait cap force-ships the closest split once players have waited too long, so nobody starves. Raise the tolerance or switch to MMR/ELO to turn it off.
LPfairness
LP is the default matchmaking mode
Done
The solver is the reason MatchKit exists, so it's now the mode a new player gets by default. MMR and ELO stay as first-class options for anyone who arrives with a specific idea of what they want.
LPdefaults
Core matchmaking engine
Done
Team formation by LP, MMR or ELO. The LP mode hands the assignment to an OR-Tools solver, which evaluates the combinations rather than pairing greedily down a sorted list. Post-match rating updates via TrueSkill or MMR. Formation and rating are independent choices.
LPOR-Toolsteam formation
Queue system
Done
Join, leave, configure, and list queues over REST. Live queue state goes to Redis or Kafka: one config key, two very different consistency stories. The matcher is ShedLock-guarded, so only one node ever resolves a queue.
queuesRedisKafka
Match lifecycle with realtime events
Done
Match found, updated, and completed events pushed over Server-Sent Events, with no polling required.
SSEreal-time
Player management API
Done
Full player CRUD over REST, with a gRPC interface for server-to-server integrations.
playersRESTgRPC
Developer accounts and API keys
Done
JWT auth for the dashboard, X-API-KEY for game servers. Keys are hashed at rest, metered per key, and the secret is shown exactly once: lose it and you rotate it.
authAPI keysJWT
Test keys can't touch production
Done
A test key is refused by the production deployment, and a live key by the test one, with an error that says which it is, rather than a bare 403 you'd spend an hour on. The prefix on the key is now enforced, not decoration. To be precise about what this is: you get a test environment, not test data sitting inside production.
API keysenvironments
Pagination on list endpoints
Done
Page controls on player, match, queue and developer listings, in both the API and the dashboard. The server caps page size, so a caller can't ask for an unbounded list by accident.
APIpagination
Developer dashboard
Done
Web console for players, queues, matches, live activity, API keys, and account management.
dashboardconsole

Building something this doesn't cover? Tell us. At this stage the order is still cheap to change.

Request a feature on DiscordRead the API reference