Skip to content
Civicore

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 — 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.