Skip to content
Home/Projects/ForgeWorks
Portfolio case study

ForgeWorks

Run local project nights from one small platform.

ForgeWorks is a Rust, Axum, and SQLite prototype for a weekly builder table. It handles project nights, RSVPs, a project board, and published recaps. It also includes sponsor, join, and community tech help pages. Member pages and operator data use separate access rules. Public launch work is in progress.

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

Keep project history and member data in one place.

Informal groups can lose project history and RSVP details. Hosted tools can place member data under another company's control. ForgeWorks keeps the community record in an operator-controlled database.

Approach

Show public pages and lock operator data.

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. An admin key protects admin routes and raw exports. It also protects unpublished recaps, member emails, Slack integration, and the SQLite database.

Build

Run Axum, SQLite, and static pages on a Raspberry Pi.

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

Separate public pages from operator tools.

Public pages show only prototype or approved public data. Admin routes and member details stay gated. Raw exports, Slack details, and operator tools stay 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

Finish the pages needed for a public pilot.

The current work prepares the public pages for a safe preview. It also adds the RSVP and tech help forms needed for a working community.

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 read-only preflight checks the public preview and confirms that admin routes reject invalid keys.
Sanitized architecture

Route visitors and operators to separate surfaces.

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 ForgeWorks 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.
  • Checking public preview safety with a repeatable script.

Public boundaries

  • Prototype with public launch work in progress.
  • Current scope excludes live membership, paid sponsors, and production-grade authentication.
  • The live demo URL is private. Admin routes, Slack tokens, and member data also stay private.
  • Repository is private and available on request.

Build a small platform around your workflow.

Bring the workflow and the privacy rules. I will scope the public pages and operator access.

Send a work request