Thousands are already on board.

Join the movement
Skip to content
Civicore
Register

Architecture

A high-level view of Civicore's architecture, including the region model and lifecycle.

Civicore is a modular monolith with a small set of well-defined modules:

  • Auth - Clerk-issued JWTs, verified server-side
  • Users & RBAC - scoped role memberships
  • Regions - IEBC-aligned hierarchy (county → constituency → ward)
  • Aspirants - profiles, manifestos, media, verification
  • Parties - party admin, roster, broadcasts
  • Campaigns - lifecycle phases, tasks, events, team roles
  • Volunteers - registration, assignments, activity logging
  • Communications - campaign live streaming, geo-targeted announcements + internal DMs
  • Analytics - cached aggregates, nightly rollups
  • Notifications - Resend email worker + push-ready record storage
  • Posts - Instagram-style stories, posts, live countdowns

The frontend (the SaaS app) runs on Next.js. The backend is NestJS with PostgreSQL, Prisma, and Redis. This documentation describes the product - the marketing site you are reading lives at the civicore.co.ke domain; the application is at app.civicore.co.ke.

Region model

Kenya's electoral hierarchy is modelled natively:

  • 47 counties
  • 290 constituencies
  • 1,448 wards

Every entity in the platform - aspirants, campaigns, events, broadcasts - is anchored to a region scope. This means a ward-level coordinator sees ward-level data, and a national party admin sees the country.