QC workshop — Brandon Werner, developer
I build practical software, developer tools, and playful products — and I care enough to test the awkward parts.
Full-stack product work, honest documentation, and quality checks that actually run. This site is the build floor for that process.
SEC. 01 / Work
The strongest builds first: real captures of what each product looks like today, with honest statuses and verified links.
Case 01 / Game / full-stack product
A mobile-first browser game with an old-school MMO influence and a blue-collar science-fiction world.
activeInspection notes
Fig. 1 — Mobile capture
Checking the equipment loadout at the crash site
More shots
Case 02 / Family product / full-stack application
A family park passport for discovering parks, recording private visits, and earning server-controlled adventure progress.
activeInspection notes
Fig. 2 — Desktop capture
The interactive Bellingham park atlas
More shots
Case 03 / Game
A playful incremental game about hiring developers and generating lines of code — an early Vite + React client prototype with a live deployment.
prototypeInspection notes
Fig. 3 — Desktop capture
Mid-game state: 286 LOC and three developers
More shots
Supporting work
Fig. 4 — Terminal output
Real Alibaba token-plan request: 41 cookies reduced to one required cookie
Developer tool / security-minded automation
A CLI that imports a copied cURL request, verifies the endpoint, and experimentally reduces authentication material to the smallest working cookie subset.
open sourceFig. 5 — Desktop capture
Browsing local thread history in Jippity
Developer experience
Linux helpers and examples that make the Codex desktop workflow easier to launch, diagnose, demonstrate, and recover.
open sourceSEC. 02 / Bench
ProvisionalThe next builds on the bench — planned and honest, not an automatic feed.
Bench 01
The typed catalog from the backlog: slugs, statuses, verified links, and screenshots for every documented project.
Bench 02
Keep the five project captures current and honest as the products evolve; capture new builds when they ship.
Bench 03
The build notebook for decisions, failures, and fixes, plus focused case-study pages.
SEC. 03 / Notebook
ProvisionalA build notebook of decisions, failures, and fixes — short technical notes, not a content mill.
Note 01 — pending
Note 02 — pending
Note — Field notes are repository-owned markdown; the first entries ship with the notebook build.
SEC. 04 / Person
The person behind the inspection marks — and the process that keeps the work honest.
I'm Brandon Werner. I work full-time at Walmart and build practical software outside that job: full-stack products, developer tools, family-focused apps, and the occasional ridiculous game idea that turns into a real system.
I didn't arrive through a traditional software career. I learn by building, testing, deploying, and reviewing the thing that actually exists — not just the version that sounded good in a plan. That means real databases, failure paths, browser journeys, Docker deployments, and sending work back for another pass when it functions but still isn't finished.
The move into professional development looks like this: one real project, one reviewable branch, one honest status at a time. Quality means evidence — tests that run, previews a person can inspect, and an accurate status on everything I publish.
Workflow note
AI is part of my workflow, not a substitute for ownership. I use models to help plan, implement, and review; I set the scope, make the product decisions, inspect the previews, validate the behavior, and decide what ships.
01
Define the outcome, the truth sources, the constraints, and the non-goals before any implementation begins.
02
One branch, one pull request. No unrelated scope, no automatic merges.
03
Pure rules, persistence behavior, and real browser journeys each receive the evidence they need — not a rigid one-size checklist.
04
Passing tests do not prove that hierarchy, spacing, interaction, or copy actually works for a person.
05
Accurate statuses and limitations. No invented users, metrics, testimonials, or maturity.
06
“Technically correct” and “finished enough to ship” are different standards, and the second one matters more.
Evidenced in the catalog
CAP. 01
CAP. 02
CAP. 03
CAP. 04
SEC. 05 / Contact
GitHub is the best place to inspect the work. LinkedIn is the best place to connect about useful tools, product work, developer workflow, or collaboration.