Solon

Problem Statement

Nigerian political campaigns run largely on intuition and disconnected tools: no rigorous way to model "what happens to vote share if turnout drops, two parties coalesce, or a fuel-subsidy shock hits," no unified field-agent coordination, and weak finance-compliance tracking. Worse, political-data tools invite abuse (voter suppression, individual-voter targeting). The challenge is to build genuinely useful campaign intelligence with hard ethical guardrails.

Proposed Solution

Solon — named after the Athenian reformer, signaling neutrality and wisdom — is a political intelligence and campaign platform. Its flagship is an Election Simulator: pick a race (President/Governor/Senate/House/State Assembly), define candidate matchups, then pull structural levers (turnout by demographic, coalitions, candidate withdrawal with second-preference redistribution, defections, boundary changes, BVAS/accreditation failure) and issue shocks (subsidy collapse, security incident, currency crash, major endorsement, scandal) — each producing projected vote share with a confidence band and a plain-language rationale. Around it sits the operational campaign stack: voter segmentation, agent coordination, finance compliance, and a live election-day war room.

Full Solution Details

Election Simulator (Module 0) — baseline scenario with confidence interval, top-5 driving variables, up to 4 candidates with rich attributes (party, demographics, incumbency, backers, platform tags), stacked levers with isolated-vs-combined impact, severity/decay-tuned issue shocks, scenario save/compare (up to 4), vote-share charts, polling-unit maps, demographic crosstabs, and branded PDF export with a mandatory disclosure footer.
Role-based access — Aspirant, Strategist, Consultancy, Journalist, Researcher, Party Office, Candidate, Campaign Manager, Ward/LGA Coordinator, Agent, Citizen Reporter, Finance Officer, Admin — driving feature gating and pricing.
Operational modules — voter segmentation, agent coordination, finance/compliance, war room.
Ethical guardrails (non-negotiable) — block voter-suppression scenarios, block individual-voter-data scenarios, standardized probabilistic-estimate disclosures on every export.

Technical Documentation

Delivered as a pnpm workspace monorepo with five deployable apps — main-backend (Express public API), data-layer (internal-only data service), solon-web (Vite/React campaign app), solon-admin-web (Vite/React ops console), solon-website (Next.js marketing) — and shared packages: core (pure TS types/routes/helpers, no React/Node), api (ky client + endpoints + react-query hooks), and ui (React + Tailwind design system). The repo enforces supply-chain and consistency discipline: pnpm-only (only-allow preinstall hook), workspace:* for all internal deps, a committed lockfile, Node ≥20 pinned via engines, and notably minimum-release-age=10080 (7 days) in .npmrc so pnpm refuses any dependency version published less than a week ago — a cheap, deliberate defense against fresh supply-chain attacks. A separate internal data-layer service isolates data access from the public API.

Tech Stack

TypeScript, pnpm workspaces, React + Vite (campaign + admin web), Next.js (marketing), Express (main-backend + data-layer), ky, react-query, Tailwind; shared core/api/ui packages.

System Design

pnpm monorepo
 apps/
   solon-web (React/Vite) ┐
   solon-admin-web (R/Vite)│ ── @org/api (ky + react-query) ──► main-backend (Express, public)
   solon-website (Next.js) ┘                                          │
                                                                      ▼
                                                          data-layer (Express, internal-only)
 packages/
   core (pure TS: types, routes, helpers)   ◄── shared by everything
   api  (network client, endpoints, hooks)
   ui   (React + Tailwind design system)

 Simulator: race → candidates → levers + shocks → probabilistic vote share
            + confidence band + rationale → save/compare → branded PDF
 Guardrails: block suppression / individual-voter scenarios · mandatory disclosures
 .npmrc: minimum-release-age=10080 (7d) · pnpm-only · workspace:* · Node≥20

Smart Architectural Decisions

Ethics encoded as product constraints. Blocking voter-suppression and individual-voter-data scenarios, plus mandatory probabilistic disclosures on every export, are built into the product — a rare, principled stance for a political-data tool.
Supply-chain hardening by default. minimum-release-age=10080 (refuse deps <7 days old), pnpm-only enforcement, committed lockfile, and pinned Node show a security-conscious dependency posture most teams never adopt.
Public API vs internal data-layer split. Separating the internet-facing main-backend from an internal-only data-layer is a clean trust-boundary decision for sensitive political data.
Layered packages with strict purity rules. core is pure TS (no React/Node), api owns the network layer, ui owns presentation — one source of truth for types and endpoints across five apps, preventing drift.
Simulator as the funnel. Designating the lowest-data-risk, broadest-audience module as the entry product is sharp go-to-market thinking encoded into the architecture.

Impacts

A serious, multi-surface political-intelligence platform — probabilistic election modeling plus a full operational campaign stack — engineered as a disciplined monorepo with explicit ethical guardrails and supply-chain defenses, for the Nigerian market.

Demonstrated Skills

Large-scale monorepo architecture (pnpm workspaces, 5 apps + shared packages, strict layering/purity); domain modeling of a complex problem (probabilistic election simulation, levers, shocks, second-preference redistribution); security engineering (supply-chain hardening, public/internal trust boundary); ethics-by-design; multi-framework delivery (Vite/React + Next.js + Express); design-system + typed API client.