Warren S. · github.com/nunchimangchi-dev

Building real, working software, in the open.

A privacy automation platform, a live full-stack app I build and operate end to end, and the dev environment they run on. All actively developed, all with real commit history, CI, and production deployments. Not one-off demos.

unbrokerrdd

View on GitHub

Go · WebSocket agent · privacy automation

What it does: A privacy automation platform targeting 85 data brokers across six planned opt-out strategy types. The first, the TruthFinder cascade, is fully operational end to end: one form submission covers 7 affiliated broker properties, and Claude's vision capability confirms the opt-out from a post-submit screenshot. Go backend with a WebSocket agent and a real-time operational dashboard.

The real decision: Strategy 1 shipped first on purpose. Highest coverage for the effort, and a way to validate the whole pattern (the screenshot-confirmation loop, the QA gates, the SQLite-backed state machine) before committing to the other five strategy types.

Current state: First strategy live and tested against the real site. The other five are scoped and registry-seeded, not started, and the README says so directly. The dashboard sits behind Cloudflare Access identity rather than a second login, gating who can run a batch versus only review one. Built and run solo. Currently exploring product-market fit.

Next.js · Prisma · Auth.js · self-hosted

What it does: A live, invite-only beta fitness accountability app (Next.js, Prisma, Auth.js) that I build and operate with full infrastructure ownership: a network-segmented LXC host, a Cloudflare Tunnel with zero inbound port-forwarding, and a separate staging environment. Google OAuth and CI/CD on a self-hosted production deployment.

The real decision: A documented, reversed access-control decision. I added Cloudflare Access in front of the app, then removed it once app-level auth proved sufficient, verified live rather than assumed. Separately, building the wagers feature surfaced a data-scoping bug in tables that had no per-user isolation, caught by checking the real database instead of trusting a clean build.

Current state: Real Google OAuth with an allowlist gate, CI on every PR, production deployment behind the Cloudflare Tunnel with a separate staging environment. A GDPR/CCPA-style data export and deletion flow backs an authored Privacy Policy. Actively developed.

chezmoi · fish · tmux · infrastructure

Supporting project. The repeatable dev-environment bootstrap the two projects above are built and deployed on: git/GitHub identity, tmux, fish, Bitwarden, and chezmoi-managed dotfiles, applied identically across a Linux server and a MacBook from one source of truth. chezmoi specifically because it reconciles real Linux/macOS differences from one config rather than maintaining two. A public build-log dashboard tracks what is done versus pending.

How I work

I scope the approach and the data model, review before code gets written, and verify after: run it, click through it, read the database directly. A green build is not proof it works.

The wagers data-scoping bug on droppdd (above) is why. It only surfaced when the tables were used the way they were meant to be. Code is cheap to produce now. The judgment about what's actually correct, and the calls on data-model and security tradeoffs, are the work.