Hargrove Campaign Platform

Problem

A public campaign website has two different responsibilities. It must explain the candidate and priorities clearly on a phone, and it must handle volunteer, contact, update, and yard sign requests without treating public input as trusted data.

The platform needed a clear public experience plus a protected operational path for form submissions.

Constraints

Campaign stakeholders owned the political content, legal language, recipient decisions, and operating process. The website needed English and Spanish behavior, mobile first navigation, accessible interaction, and reliable failure messages.

Public forms also created an abuse and privacy boundary. The system had to reject unsupported fields, constrain request size, validate field values, verify a human interaction, and avoid exposing private campaign operations.

Ownership

I built the web platform and its form processing path. My responsibilities covered the Astro application, responsive interface, localized form behavior, request validation, bot protection, delivery coordination, and release checks.

I did not own campaign strategy, candidate claims, legal approval, or campaign outcomes. This case study keeps operational details sanitized and does not publish private contact information.

Decisions

I used Astro to keep the public pages direct and lightweight while reserving server execution for actions that require it. The form endpoint accepts a fixed set of form types and fields rather than storing arbitrary request content.

Validation occurs before delivery. The endpoint checks body size, field count, field names, value shapes, required values, email and phone formats, campaign specific choices, source paths, locales, and submission identifiers.

Turnstile verification protects the action boundary. Successful requests are coordinated to email notification and structured submission storage. Failure responses are localized and avoid revealing private configuration.

Implementation

English and Spanish Astro pages submit structured requests to a Cloudflare edge handler. The handler normalizes values, applies form specific rules, rejects cross origin or malformed requests, and verifies the Turnstile token.

The delivery layer coordinates a campaign notification and a structured record for campaign operations. Duplicate protection applies where repeated subscriptions would otherwise create redundant records. The endpoint returns explicit failure responses when required delivery cannot complete.

The public architecture omits recipient addresses, secrets, internal identifiers, and private campaign process details.

Result

The public website is live and provides an inspectable frontend for the campaign. Private repository history and tests support my implementation claims. The sanitized architecture explains the protected form path but does not independently prove authorship.

The live site proves availability of the public pages. It does not prove successful submission volume, delivery reliability over time, voter engagement, conversion, or campaign impact.

Limitations

No private submission was sent while preparing this case study because doing so would mutate campaign data. Form delivery and campaign operations therefore remain outside the publicly verified result.

Traffic, accessibility scores, conversion, subscriber counts, and political outcomes are intentionally not claimed. Campaign content and translations remain subject to stakeholder and qualified review.

Reflection

Public forms are small distributed systems. A useful form needs clear interaction, strict input policy, bot resistance, controlled delivery, privacy aware logging, and honest failure behavior.

The project reinforced that a static first site can stay simple while still placing strong controls around the few actions that change external state.