Building a Shared Civic Platform for Tuolumne Together and Sierra Mutual Aid

Project snapshot

Client / context: Tuolumne Together and Sierra Mutual Aid

Role: Full-stack design engineer

Focus: Civic platform strategy, multi-brand product architecture, community participation UX, shared identity, publishing, events, and operational tooling

Stack: Next.js, React, TypeScript, Tailwind CSS, shadcn/ui, PocketBase, Appwrite, OpenAI, Pol.is, Turnstile, pnpm workspaces

Live sites: tuolumnetogether.org and sierramutualaid.org

One-line version

I designed and built two distinct community platforms on a shared full-stack foundation, giving Tuolumne Together and Sierra Mutual Aid their own public identities while connecting membership, events, publishing, participation, and operations behind the scenes.

The challenge

Tuolumne Together and Sierra Mutual Aid serve related but different community needs.

Tuolumne Together focuses on collective dialogue, civic collaboration, local news, and grassroots digital democracy. Sierra Mutual Aid focuses on neighbor-to-neighbor support, community needs, volunteer participation, and practical local resilience.

The product challenge was not simply to launch two websites. It was to create an ecosystem that could:

• give each organization a clear identity and purpose
• let one person use the same account across both sites
• publish events across organizational boundaries
• support public and members-only information
• protect sensitive event details until someone RSVPs
• give contributors appropriate tools without giving everyone administrator access
• support editorial and event workflows that community teams could actually operate
• evolve as a shared platform without forcing both sites into the same interface
• ship as two independently deployable products with reusable foundations

The result needed to feel local and approachable on the surface while remaining coherent, secure, and maintainable underneath.

My role

I designed and built the platform end to end:

• translated two community missions into distinct product experiences
• designed the public information architecture and responsive interface patterns
• consolidated the applications into a pnpm monorepo
• built shared UI, authentication, authorization, event, and utility packages
• implemented a cross-site account and membership model
• designed role-based event and newsroom workflows
• built public, member, contributor, and administrator experiences
• implemented event publishing, RSVP, attendee, visibility, and location-privacy rules
• created AI-assisted event intake from uploaded flyers
• supported the migration from split backend services toward PocketBase
• integrated Pol.is and Signal participation pathways
• added independent build, typecheck, lint, test, and deployment boundaries for each app

Selected work

1. Two community identities, one product ecosystem

The two organizations needed to feel connected without becoming interchangeable.

For Tuolumne Together, I designed an experience centered on:

• grassroots digital democracy
• structured dialogue and collective insight
• local news and public-interest publishing
• community events
• Pol.is participation
• Signal and Facebook community pathways
• relationships with local partner organizations

For Sierra Mutual Aid, I designed an experience centered on:

• neighbor participation
• community support and local resilience
• events and practical coordination
• open product-shaping conversations
• clear sign-up and member pathways
• direct connection to mutual-aid activity

Each site has its own visual hierarchy, content emphasis, navigation, and calls to action. The shared system appears where it helps the community, not where it would flatten the organizations into one brand.

2. Monorepo architecture for independent products

I consolidated the work into a monorepo containing two independently deployable Next.js applications:

• apps/tuto-frontend
• apps/sierra-frontend

Shared packages hold reusable foundations:

• @repo/ui
• @repo/shared-utils
• @repo/core-auth
• @repo/core-events
• shared TypeScript and ESLint configuration

This structure lets the products reuse proven behavior without coupling every release. Each app can be developed, linted, typechecked, built, and deployed independently, while changes to shared packages validate both applications.

The architecture turned duplicated websites into a small platform.

3. One account across both communities

A member should not have to understand the platform architecture to participate.

I designed a shared authentication experience so one account can work across Tuolumne Together and Sierra Mutual Aid. Login, registration, verification, password reset, session refresh, and account settings follow a consistent model across the two sites.

Behind that simple experience is a capability layer that resolves:

• which platforms a person can access
• whether a membership is active
• which roles a person holds for each platform
• what event, publishing, membership, or administrative actions those roles permit

The interface presents a unified member experience while the backend preserves platform-specific access boundaries.

4. Cross-platform events with real privacy rules

Community events were a natural shared surface, but they introduced product and security questions that a basic calendar does not solve.

I built a unified event model supporting:

• Tuolumne Together and Sierra Mutual Aid ownership
• public and members-only visibility
• draft, published, and cancelled states
• human-readable event slugs
• cover photos and rich descriptions
• time zones, locations, links, and addresses
• RSVP enablement and guest counts
• cross-platform event discovery
• soft deletion and audit-friendly ownership fields

I also designed a privacy rule for events with sensitive locations: an address can stay hidden until a member has an active RSVP, while event managers retain the access needed to coordinate the event.

That logic is shared at the domain layer, so it is applied consistently across public pages, member views, and management tools.

5. Role-based contributor and administrator workflows

Small community organizations need more than an admin-or-nothing permissions model.

For events, I created role-specific capabilities for:

• platform administrators
• event managers
• event writers

An event writer can create and maintain their own drafts without being able to publish, edit other contributors' work, or change events across platforms. Managers can review, publish, update, and coordinate RSVPs.

For Tuolumne Together's newsroom, I built a governed editorial workflow with writer, approver, and publisher responsibilities across:

• draft creation
• submission for approval
• approval or rejection
• publication
• images, author information, dates, and slugs
• Pol.is conversation references
• workflow and audit metadata

The goal was to make safe delegation possible instead of making one person the bottleneck for every update.

6. AI-assisted event intake with human control

Community event information often arrives as a flyer rather than structured data.

I designed and implemented an AI-assisted workflow that can inspect an uploaded event image and suggest:

• title
• description
• start and end time
• time zone
• location name
• address
• location URL

The system validates file type and size, restricts the workflow to authorized event contributors, reports missing or ambiguous details, and avoids silently overwriting fields the editor has already changed.

This is the kind of AI feature I value: it removes transcription work while keeping a person in control of the published record.

7. Publishing and participation, not just pages

The sites needed to support ongoing community activity rather than act as static brochures.

I built product surfaces for:

• local news and editorial publishing
• upcoming and past community events
• event detail and RSVP flows
• member dashboards and settings
• membership administration
• Pol.is-powered public conversation
• Signal invitation flows
• public calls to participate, contribute, and organize

The interaction design moves people from learning about the organizations to taking a concrete next step.

8. Backend migration without pausing the product

The platform evolved across Appwrite and PocketBase rather than starting from a perfectly clean backend.

I built adapters, migration scripts, setup scripts, and bridge code to move authentication, events, memberships, RSVPs, and news toward a clearer PocketBase-centered model while preserving necessary Appwrite-backed media and legacy behavior during the transition.

That work included:

• normalized client and server adapters
• environment-driven collection configuration
• collection setup and migration scripts
• compatibility paths for existing user and image data
• server-side session refresh
• capability resolution with safe fallbacks
• consistent API error handling

The migration strategy allowed product work and operational use to continue while the foundation improved.

9. Production-minded design engineering

I treated the operational surface as part of the product.

The platform includes:

• responsive layouts and shared component primitives
• server-rendered metadata for event pages
• authenticated and public route boundaries
• bot protection for sign-up workflows
• reusable loading, empty, success, and error states
• package-level tests for shared domain behavior
• independent lint, typecheck, and build commands
• path-filtered CI so each application validates only when relevant
• configuration and setup documentation for future operators

That made the work maintainable by more than the person who originally built it.

Design engineering approach

Share systems, not identities

The two sites reuse domain logic, components, and infrastructure, but their public experiences remain specific to their missions. Shared code is an implementation advantage, not a reason to erase product differences.

Put permissions in the domain model

I did not treat authorization as a collection of hidden buttons. Event ownership, publishing status, membership, RSVP access, and platform roles are explicit rules that the API and interface can share.

Design for community operators

The administrative experience matters as much as the homepage. Contributor roles, review states, image tools, event extraction, and clear management screens reduce the amount of technical help required to keep the sites useful.

Keep AI assistive

AI suggests structured event information; people review and publish it. Ambiguity is surfaced instead of disguised as confidence.

Build the platform through real use cases

Shared packages emerged from concrete needs across the two sites: account access, event authorization, RSVP privacy, publishing, and UI consistency. This kept the platform layer useful and prevented abstraction from becoming the product.

Impact

The project created a connected digital foundation for two local community organizations.

It delivered:

• two distinct, responsive public websites
• one account model across both communities
• platform-specific membership and role capabilities
• a shared cross-platform event calendar
• RSVP and attendee workflows
• members-only event visibility
• conditional protection for sensitive event locations
• delegated event and newsroom publishing
• AI-assisted event flyer transcription
• Pol.is and Signal participation pathways
• reusable UI, auth, event, and configuration packages
• independent application build and deployment boundaries
• a migration path from fragmented services toward a clearer backend model

The most important result is structural: the organizations can present different community missions while sharing the expensive, invisible work required to operate a trustworthy digital platform.

What made this hard

The work crossed product design, interface design, backend architecture, authorization, migration, and community operations.

The hardest parts were:

• balancing shared infrastructure with distinct organizational identities
• making one account feel simple across two permission domains
• designing event privacy rules around real community safety needs
• allowing contributors to help without granting excessive access
• keeping public and members-only event views consistent
• migrating backend responsibilities while the products continued to evolve
• designing AI assistance that saves time without taking editorial control
• turning a pair of websites into a maintainable platform without overengineering it

Why it matters

Community technology often fails in one of two ways: it is visually polished but operationally shallow, or functionally powerful but too difficult for real people to maintain.

This project demonstrates a different approach. I treated public pages, account flows, contributor permissions, event privacy, editorial workflows, backend adapters, and deployment boundaries as one connected design problem.

The result is not just two websites. It is a shared civic operating system for participation, publishing, events, and community coordination—expressed through two organizations with different identities and a common regional purpose.