Skip to content
Home/Projects/ForgeWorks
Portfolio case study

ForgeWorks

Local builder community platform (working repo: ForgeTable)

A Rust + Axum + SQLite prototype for organizing a weekly local builder table — project nights, RSVPs, a project board, published meeting recaps, sponsor and join pages, and a community tech help intake — designed around an explicit public/private boundary between member-facing pages and operator-only data. Public launch polish is in progress; the platform is not a finished public product.

Back to projects In development Private repo / available on request Public pilot polish in progress
Problem

Builder communities lose memory or leak signal

Local technology communities tend to swing between two failure modes: stay fully informal — no project memory, no recap trail, no RSVP signal — or over-tool with SaaS that ends up owning the member data. ForgeWorks explores an operator-controlled middle path that preserves a builder community's history without leaking private signal.

Approach

A small public surface, a gated admin surface

The platform draws an explicit public/private boundary into the architecture. Public pages cover the homepage, project board, published recaps, sponsor page, public events, a community tech help intake, and a join page. Everything else — admin routes, Slack integration, raw exports, unpublished recaps, member emails, and the SQLite database — stays behind an admin key.

Build

Rust backend, static front, operator CLI

The current build is a single Axum HTTP service backed by SQLite, with static HTML/CSS/JS for public pages and a Rust ft CLI for operator-side tasks. A Python "Scout" Slack bot skeleton is kept intentionally separate from the public surface. The deployment target is a Raspberry Pi. The current focus is public launch polish: data-driven home counts, an RSVP flow, a Tech Help Night intake, and a public pilot confidence check.

Boundary proof

Public-safe surface separated from operator-only work

The proof is the boundary: prototype/public-safe data can be shown on public pages, while admin routes, member details, raw exports, Slack details, and operator tools stay gated or private.

Public-safe

Member-facing surface

Homepage, project board, published recaps, public events, sponsor/join pages, and Tech Help intake acknowledgement.

Gated

Admin / operator surface

Admin routes, raw exports, unpublished recaps, member email fields, SQLite contents, ft CLI workflows, and Scout details stay private.

Data boundary

Prototype data only

Public examples use prototype or public-safe records only. No route secrets, admin keys, Slack tokens, member emails, or private community data are exposed.

Public launch polish

A small set of credible public surfaces

The launch focus is not new features — it is making the public surface honest, current, and safe to preview, then adding the minimum interaction (RSVP, tech help) that a working community actually needs.

01 One source of truth for build metadataPublic version, member count, and project count come from a single API endpoint so footers cannot drift.
02 Data-driven homepageNext meeting, members so far, and projects on the board are read from the live API instead of hard-coded copy.
03 RSVP flowA single dated CTA replaces a scattered hero and captures interest without requiring a higher-commitment sign-up.
04 Tech Help Night intakePublic form posts to a stored request with only a public acknowledgement; the queue is admin-key-gated.
05 Public pilot confidence checkA scripted, non-mutating preflight verifies the public preview is safe and admin routes reject invalid keys.
Sanitized architecture

Public pages on one side, operator surface on the other

This public-safe architecture view shows the public pattern without exposing private repository links, local demo URLs, admin keys, Slack tokens, member emails, or non-public implementation details.

Visitor Member or guest

Browses public pages or submits an intake form.

Public pages Home, projects, recaps, events, sponsors, join, tech help

Static HTML rendered by the Axum service.

Public API Read-only summaries and intake POSTs

Returns counts, public recaps, and acknowledgements only.

SQLite Single operator-controlled store

Members, projects, recaps, RSVPs, and tech-help requests.

Admin gate Admin key required

Admin routes reject invalid keys and stay off public pages.

Operator surface ft CLI and Slack Scout (private)

Operator-only tooling kept separate from the public site.

What the case study demonstrates

  • Designing a small, owner-controlled community platform without importing a heavy SaaS dependency.
  • Drawing an explicit public/private data boundary into the architecture instead of bolting it on later.
  • Using a typed Rust backend with SQLite and a separate operator CLI so the public surface stays small.
  • Treating "is this safe to show in public preview?" as a scripted check, not a feeling.

Public boundaries

  • Prototype with public launch polish in progress; not a finished public product.
  • No public live membership, no paid sponsors, and no production-grade auth are claimed.
  • No public live demo URL is exposed; admin routes, Slack tokens, and member data stay private.
  • Repository is private and available on request.

Need a small, owner-controlled platform with a clear public/private line?

Bring the workflow and the privacy constraints. The platform should respect both.

Request a Local Tech Assessment