/building-in-public
Share the reasoning. Protect the secrets.
Building in public, done honestly. The useful part of the work — architecture lessons, practical checklists, experiments, reusable patterns, project notes, and selected code — can be shared openly. Useful transparency does not require publishing credentials, confidential systems, or every implementation detail.
This is not an "everything I make is open source" claim. It's a working line between the reasoning that helps people and the secrets that should stay closed.
What I share
The reasoning, generously
Everything here is supported by work already public on this site — lessons meant to be reused, not a catalog of source code.
-
Architecture reasoning
The thinking behind a design — trust boundaries, constraints, and why a system is shaped the way it is — written so you can reuse the reasoning, not just the result.
-
Implementation tradeoffs
The honest "this, not that" calls: what each option costs, what it buys, and the conditions under which the answer would flip.
-
Validation and review patterns
How work earns trust — dry-runs, small reviewable slices, check / build / test gates, and human sign-off on anything that matters.
-
Useful checklists
Lightweight playbooks and worksheets pulled straight out of the workflow, on the /resources shelf — steal whatever's useful.
-
Project case studies
Write-ups of real builds and earlier chapters of independent work, framed so the lessons travel even when the specifics don't.
-
Experiments and lessons
Half-built prototypes and weird ideas from the lab, including the ones that didn't pan out — the failure is often the most useful part.
-
Selected public code
Specific repositories or snippets when a confirmed public URL exists — never a private project dressed up as open source.
What stays private
The secrets, on purpose
Clear boundaries, kept calmly. None of this needs to be public for the work to be genuinely transparent.
-
Credentials and secrets
Keys, tokens, and passwords live in dedicated secret stores — never pasted into a prompt, committed to git, or printed into a public write-up.
-
Private network and access details
Internal topology, hostnames, and the specifics of how to reach private systems stay out of public material.
-
Employer information
Public work is independent and built from original architecture and public docs. It doesn't carry employer-internal knowledge or imply endorsement.
-
Client-confidential material
Anything shared in confidence stays that way. Case studies are written so the lesson survives without exposing a client's private details.
-
Unreleased implementation details
Product work still being finalized — currently the working concept referred to as NexusPort — is discussed at the level of ideas, not shipped internals.
-
Active attack-surface information
Specifics that would help someone attack a live system get withheld or generalized. Security-minded sharing doesn't hand out a map.
-
Private conversations
DMs, threads, and one-to-one discussions aren't republished. Permission and context matter more than a good quote.
-
Proprietary source code
Private and commercial code stays private. Sharing the reasoning behind it is generous; publishing the code itself is a separate, deliberate choice.
What makes it useful
A good public artifact earns its place
Sharing isn't the same as helping. These are the things that make a public write-up worth someone's time.
- 01
Explain the problem and constraints
Start with what you were actually trying to do and what you were boxed in by. A solution without its constraints is hard to reuse.
- 02
Show the important tradeoffs
Name the real alternatives and why this one won. The decision is usually more transferable than the code.
- 03
Separate fact from opinion
Be clear about what's measured, what's experience, and what's a hunch — so readers can weigh it instead of inheriting it whole.
- 04
Include the failure modes
Say where it breaks, what didn't work, and what you'd watch for. The edge cases are the part people can't easily rediscover.
- 05
Give enough context to adapt it
Enough surrounding detail that someone on a different stack can translate the lesson, instead of cargo-culting the exact steps.
- 06
Don't pretend one stack fits everyone
What works here isn't a universal law. Frame it as one good answer for a context, not the answer for all of them.
- 07
Date it and update it
Technical truth has a shelf life. Clearly date information and revise it when the world changes, rather than leaving stale advice standing.
Selected artifacts
Where the reasoning already lives
A curated path through the public work on this site. Each one is a real page — follow whichever matches the problem you're chewing on.
- Process How I build The whole loop in one place: small slices, safety rails, and tight feedback loops, walked through step by step.
- Principles Trust The security and access defaults behind the work — least privilege, secrets handling, and human-owned review.
- Field note Security Is Architecture, Not Decoration Why security belongs in the design from the start, not bolted on as a feature after something breaks.
- Field note Automation Needs a Panic Button Dry-run mode, rollback thinking, and the guardrails that keep automation a small, recoverable mistake.
- Field note Small Slices Beat Big Bang AI How narrow, validated steps beat heroic rewrites — especially with an AI agent in the loop.
- Field note AI-Assisted Development Without Losing the Architecture Keeping architectural judgment human while AI accelerates the typing, not the decisions.
- Field note Documentation Is Infrastructure Why the write-up is part of the build — the reasoning that survives after the code changes.
- Case study Private Cloud / Homelab What running real infrastructure at home teaches about the messy operational parts most tutorials skip.
- Case study Duvall WiFi An earlier chapter of independent technical work, written up so the approach travels past the specifics.
- Experiments Lab Half-built prototypes and small ideas, shared before they harden into systems — process in the open.
- Playbooks Resources Reusable checklists and templates for AI slicing, safe automation, and security-minded launches.
Public code and GitHub
When code is genuinely public, it lives on GitHub. There's no curated repository list here on purpose — this page won't query GitHub at build time or quote live star, follower, or commit counts, and it won't dress a private project up as open source.
If a repository is public and worth your time, the profile is the honest place to find it.
Join in
How to participate
Building in public is a two-way thing. If something here is useful, wrong, or sparks an idea, that's worth a message — no contribution guidelines to memorize.
- Share a correction when something here is out of date or just wrong.
- Discuss an article — push on the reasoning or add the case it missed.
- Suggest a useful resource or checklist worth adding to the shelf.
- Propose a collaboration if our work overlaps.
- Bring a messy technical question — the half-formed version is fine.
The useful part of the work is often the reasoning that survives after the code changes.