KVN
System registry
SYS-0062026-06–present

Matchday

A production team-management product that keeps players, matches, availability, tactics, ratings, and reminders in one shared system.

TypeProductEngagementOwnedTierCase StudyStateProductionActivityActive Development
Open Matchday
01

Context

Matchday gives amateur football teams one team-scoped place for membership, availability, matches and training, RSVP, results, lineups, ratings, announcements, comments, and web-push reminders. Server-side membership and role checks protect every team resource, while scheduled work materializes recurring events, deduplicates reminders, and delivers notification work outside normal request handling.

Core engineering problem

Replace an ad-supported team app with paid limitations by keeping the team's schedule, player availability, planning, and communication in a product I control.

Small football teams still need clear coordination boundaries: membership, roles, availability, RSVP, who can edit an event or lineup, and when a reminder has already been sent. Matchday centralizes those responsibilities without treating ordinary team administration as enterprise infrastructure.

  • Scope every team resource through membership and avoid disclosing another team's resource existence to non-members.
  • Let coaches and administrators control team-level mutations while preserving appropriate player self-service.
  • Give every recurring training occurrence independent RSVP, lineup, comments, and reminder state.
  • Support several team sizes, formation seeding, manual player placement, and attending-player selection.
  • Make scheduled reminder checks safe to repeat without duplicate messages.
  • Keep browser authentication, API delivery, and web push within a same-origin production boundary.
02

My role

I designed, built, deployed, and operate Matchday across its product rules, backend, frontend, notification system, and runtime.

Contribution boundaries

  • Product OriginMatchday responds to a practical team need after another application introduced ads and paid limitations; it is not presented as a wholly novel category.
  • AdoptionThe product runs correctly in production, but expected users currently engage only intermittently.
Owned

Product Direction

Requirements shaped around the team's need for an ad-free, unrestricted coordination tool.

OwnedDesignedDirected
Architected

Application Engineering

Django API, React interface, team-scoped permissions, events, attendance, tactics, ratings, and communication workflows.

ArchitectedModelledImplementedMaintainedReviewed
Designed

Notification Delivery

Scheduled reminders, background web-push delivery, subscriptions, and notification navigation.

DesignedImplementedIntegratedMaintainedReviewed

Deployment And Operations

Containerized application, database, queue, workers, public routing, and production operation.

DesignedImplementedDeployedOperatedMaintained
03

Architecture

Level 01 / System

System context

08 boundaries · 10 declared relationships

  1. 01Installable Matchday web applicationClient
  2. 02React team interfaceService
  3. 03Django REST APIAPI
  4. 04PostgreSQL team data storeDatastore
  5. 05Background-work brokerQueue
  6. 06Reminder and notification workersWorker
  7. 07Browser push serviceExternal Provider
  8. 08Containerized production runtimeInfrastructure
Relationship mapInspect 10 connections
  • Installable Matchday web applicationRequestReact team interface
  • React team interfaceRequestDjango REST API
  • Django REST APIPersistencePostgreSQL team data store
  • Django REST APIAsyncBackground-work broker
  • Background-work brokerAsyncReminder and notification workers
  • Reminder and notification workersNotificationBrowser push service
  • Containerized production runtimeHostingReact team interface
  • Containerized production runtimeHostingDjango REST API
  • Containerized production runtimeHostingPostgreSQL team data store
  • Containerized production runtimeHostingReminder and notification workers
04

Engineering decisions

01

Make membership the team security boundary

Context

One user can participate in several teams and hold a different role or player profile in each.

Selected approach

Use membership as the User-to-Team spine and enforce team scope and role checks in API querysets, permissions, and actions.

Rationale

Keep identity global while making team-specific authority and player state explicit.

Trade-offs

  • Every resource lookup needs membership context.
  • Profile changes must distinguish global user data from team-specific membership data.
02

Materialize recurring training as real events

Context

Each training occurrence needs its own RSVP, comments, lineup context, cancellation, and reminder state.

Selected approach

Persist a recurrence rule and materialize individual Event rows.

Rationale

Let downstream workflows treat every occurrence as an ordinary event with independent state.

Trade-offs

  • Generation must prevent duplicate occurrences.
  • Later series edits require an explicit product policy.
03

Seed formations but persist free lineup coordinates

Context

Team sizes and formations provide useful starting structures, but coaches need to move players freely.

Selected approach

Generate starter slots from a validated formation, store normalized coordinates, and enforce unique lineup membership.

Rationale

Combine quick setup with flexible tactical positioning and responsive rendering.

Trade-offs

  • Coordinate rendering must adapt across screen sizes.
  • Position meaning and visual placement remain related but distinct data.
04

Make reminder checks repeatable without duplicate messages

Context

Periodic workers may run late, retry, overlap, or evaluate several reminder thresholds at once.

Selected approach

Use unique event/rule delivery claims, select the most urgent due rule, and queue push delivery separately.

Rationale

Make repeated checks safe while keeping external delivery latency out of normal request handling.

Trade-offs

  • Delivery records add persistent operational state.
  • Broker failure requires an explicit fallback policy.
05

Use same-origin session authentication for the web product

Context

The current client is a browser application served with its API under one origin; a future mobile app remains possible.

Selected approach

Use headless browser sessions with secure cookies and CSRF while retaining an API-first backend.

Rationale

Keep browser credentials out of application JavaScript and preserve server-side session revocation.

Trade-offs

  • Deployment depends on correct same-origin proxy and cookie settings.
  • A future native app will need a separate supported authentication mode.
05

Runtime ownership

  1. 01
    Containerization

    Compose separates the frontend, API, database, queue, worker, and scheduler services.

  2. 02
    Reverse Proxy

    Host-level routing serves the application and API through one public origin.

  3. 03
    Hosting

    I deployed and operate the production application.

  4. 04
    Storage

    PostgreSQL persists product state while the queue supports background and scheduled work.

  5. 05
    Logging

    Push failures are logged and permanently invalid subscriptions are pruned.

  6. 06
    Scheduled Tasks

    A periodic scheduler evaluates RSVP, kickoff, and score-entry reminders from event state.

    Inspect operational detail
    • Unique event/rule records keep repeated checks from delivering the same reminder twice.
  7. 07
    Background Jobs

    Web-push delivery runs through queued workers with a guarded fallback when the broker is unavailable.

  8. 08
    Notifications

    Application actions and scheduled rules produce team-scoped web-push notifications.

  9. 09
    Deployment

    The production container stack is served behind host routing with the application and API on one origin.

    Inspect operational detail
    • The production application was reachable during portfolio intake.
06

Current state

  1. Current

    Matchday is deployed in production and is used intermittently by its intended team users.

  2. Lesson

    Use team membership as the shared boundary for team data and permissions.

  3. Lesson

    Keep a persistent record of sent reminders so retries or overlapping scheduled checks do not send duplicates.

  4. Lesson

    A working production product does not guarantee engagement; adoption and engineering correctness are separate questions.

Depth B / Technical inspection

Inspect supporting evidence

Domains, provider boundaries, and evidence classifications.

T1

Domain structure

  • Identity and authenticationCustom email users, session authentication, password recovery, verification, and future social/mobile compatibility.
  • Teams, memberships, and rolesMulti-team membership, coach/admin/player roles, join codes, switching, captaincy, availability, jersey numbers, and positions.
  • Events, RSVP, and resultsMatches, training, meet and start times, recurrence, attendance states and reasons, cancellations, scores, and team record.
  • Tactics and lineupsTeam-size formats, formation seeding, normalized free placement, starter/bench roles, attending-player selection, and position context.
  • Player ratingsTeam-defined attributes, standing or match-specific ratings, visibility rules, bulk entry, and bounded values.
  • Announcements and event commentsPinned team notices and event-specific coordination threads authored within team membership scope.
  • Reminders and web pushBrowser subscriptions, RSVP and kickoff rules, score-entry nudges, idempotent scheduling, background delivery, and notification navigation.
  • Installable web deliveryResponsive React application, installable manifest assets, service-worker precaching, and push handling.
T2

Integrations

  • Push NotificationsBrowser Web Push

    Deliver RSVP, kickoff, score-entry, event, lineup, and team communication reminders outside an active browser session.

    Standards-based web push with application-managed subscriptions
T3

Capability evidence

  • Product and system ownershipI own the product direction, source, full-stack implementation, deployment, operation, and review.
  • System architectureI designed the browser, API, persistence, queue, worker, scheduler, and notification boundaries.
  • API designI implement team-scoped APIs for memberships, events, attendance, tactics, ratings, communication, and notifications.
  • Frontend deliveryI built the responsive React interface for team, squad, schedule, event, tactics, ratings, settings, and join flows.
  • Domain modellingI model team memberships, player state, events, attendance, lineups, ratings, and communication as related domain records.
  • Authentication and authorizationI enforce membership scope, role gates, and self-service boundaries server-side.
  • Transactional workflowsI use database constraints and atomic claims to protect reminder, lineup, rating, and team-state changes.
  • Background processingI run scheduled reminder evaluation and web-push delivery outside normal request handling.
  • Systems integrationI integrate standards-based browser push through application-managed subscriptions.
  • Relational persistenceI persist team, membership, event, attendance, lineup, rating, communication, and reminder state in PostgreSQL.
  • Deployment and operationsI deploy and operate the containerized production application, queue, workers, and scheduler.
  • Automated testingI maintain regression coverage for team scope, role gates, joins, events, reminders, tactics, ratings, and persistence constraints.