SADA: Political Electoral Registry Web App

Project Overview

SADA is a purpose-built internal CRUD web application for managing the political-electoral registry (padrón) of a political party in San Antonio de Areco, Buenos Aires province. It replaces manual spreadsheet workflows with a secure, multi-user dashboard that reads and writes directly to a Google Sheets backend, with no traditional database required. The system handles voter records across 34 data fields, supports political classification (MDF vs. OTRO), tracks party membership, and provides analytics, export tools, and a bulk address review workflow.

Objectives

• Centralized Registry Management - Provide a single, access-controlled source of truth for voter and affiliate data replacing fragmented spreadsheet operations.
• Political Classification - Surface and manage the key AFINIDAD field (MDF | OTRO) across all views to support internal campaign decisions.
• Data Quality - Implement a structured address-review workflow (VALIDA / REVISION / ERROR) to clean and verify existing registry addresses.
• Export & Reporting - Enable one-click exports of the full registry, birthday lists, address reports, individual member profiles, and analytics, in both XLSX and PDF formats.
• Secure Multi-user Access - Authenticate users via Google SSO with a whitelist maintained in the same Google Sheet, tracking which internal contact contributed each record.

Project Workflow

• Design System First - Visual identity was defined upfront using an editorial design language inspired by Argentine Peronist political graphics: bold typography (Space Grotesk + Inter), high-contrast primary blue (#0253cd), and a strict no-border rule using color layering and whitespace instead.
• Schema Design - A 34-column Google Sheets schema (BASE tab) was designed and versioned (v2 → v2.1) with column-map abstraction in code to prevent index drift across migrations.
• Next.js App Router Architecture - All protected routes live under a single authenticated layout. Server Components handle initial data fetching; URL Search Params persist filter state across navigation.
• API Layer - REST-style route handlers manage the full CRUD lifecycle: list with filtering and pagination, create, full-record update, logical soft-delete (ESTADO → INACTIVO), and a dedicated address-correction endpoint that writes only specific columns without touching read-only fields.
• Analytics Panel - A dedicated /analytics view aggregates totals and breakdowns by circuit, age range, gender, and affiliation year, reusing the same filtered dataset and powering PDF report generation.
• Mobile Responsiveness - Iterative fixes addressed overflow, bottom navigation clipping, and layout breaks across the entire protected area.
• Audit Logging - Edits are logged to a LOGS sheet with timestamp and user email, providing a traceable record of who changed what.

Results and Impact

• Functional Internal Tool - The application was developed from zero to a feature-complete internal tool in a single day of intense iteration, reaching 39 commits covering CRUD, auth, analytics, exports, address review, and mobile fixes.
• Data Integrity - The schema versioning approach and column-map abstraction eliminated index-drift bugs that would have silently corrupted records in a direct-index implementation.
• Audit Trail - Every edit is attributable to a specific internal user, giving the party organization visibility into data provenance.
• Export Flexibility - Staff can export any filtered view of the registry to XLSX or PDF without technical assistance, reducing operational bottlenecks.