bradtraversy.dev is the public home of my solo work. the side projects, dev tools, and saas products i build outside of traversy media.
what’s here
four kinds of content, each pulling its weight differently:
- articles: polished writeups. low cadence, high quality. “how my five-profile agent fleet actually works”, “from prototype to prod in 6 weeks”, that kind of thing.
- devlog: raw notes from the workbench. shipped, broke, fixed, decided. medium quality, written as i go. often pulled straight from session logs i keep in obsidian.
- projects: the major ongoing work. vidpipe (paid saas), devsheets (free dev directory), repo-reviver (oss cli), mission control (internal homelab dashboard), and the homelab itself. each project gets a real page with status, stack, and a “how it’s built” trail back to articles and devlog entries.
- tools: the long catalog tail. small one-day utilities. eyebreak, typesmith, webutils, and however many more end up here.
why this exists
i ship a lot.
a paid saas with real revenue. half a dozen free dev tools. an open-source cli. an internal dashboard that runs my homelab. a five-profile autonomous agent fleet that’s deeply non-standard. the occasional weekend prototype that gets killed two days later.
the problem: nothing connects them. youtube is the school. the obsidian vault is the workshop. but there’s no public surface that says “here’s what’s actually being built right now, here’s what shipped last week, here’s what got killed and why.”
bradtraversy.dev is that surface. one page per project, with the build documented in the open. one stream of devlog entries pulled from real session notes. a catalog of tools so the small things don’t just become a tweet that scrolled away.
why “lab”
because that’s what it is. not a marketing site. not a portfolio. not a startup landing page. a public-facing window into the work, whether that work is finished, in-progress, or abandoned.
a lab implies experiments. some of these projects are going to die. some are going to ship and earn revenue. some are going to be open-source utilities a handful of people use forever. the framing matters: the value is in the doing, not just in the polished output.
the agent angle
i use claude code (in the terminal, on this laptop), cowork (claude desktop, on my mac), and a five-profile autonomous fleet running on my homelab via hermes: sysadmin, developer, creator, secretary, keeper, one profile per lane. they all share a vault. they read each other’s session logs. they pick up tasks from each other through a shared task queue.
it’s not a research project. it’s the actual setup that ships vidpipe, polishes devlog drafts, writes commit messages, and keeps the whole operation moving. the full tour is in how the agent fleet works.
what this isn’t
worth saying out loud so the framing is clear:
- not a tutorial blog. “how to use react” posts are on traversy media. this is the lab; the school is somewhere else.
- not a course site. if you want to learn web dev or build along, that’s a different surface.
- not a portfolio. no “hire me” page, no client testimonials, no agency framing.
- not a marketing site. vidpipe is paid, but you won’t find pricing here. pricing lives on vidpipe’s own page. this is the lab; the actual product is somewhere else.
what’s left is the work, the writing about the work, and a way for people to follow along if they want.
the design choice
if you’re reading this on the site, you’ve noticed it doesn’t look like a normal blog. the chrome is a vscode editor metaphor: title bar, tab bar, activity bar, status bar. the article body shows up in the editor pane, with line numbers in the gutter and headings prefixed with ## like markdown.
deliberate aesthetic choice. this is a place where work happens, and the lab should look like the place where the work happens. i build in vscode every day; the site should feel like the workbench, not the gallery.
low-key opinion: the editor is the brand. you don’t have to like it, but you’ll know whose site it is.
what to expect
cadence:
- articles: 1–4 per month, when something’s worth a polished writeup
- devlog: whenever. often daily during a sprint, weekly otherwise. raw, time-stamped, usually pulled from a vault session log via a small skill that strips the internal stuff
- projects: updated as work ships phases or changes status
- tools: added as the catalog grows
- newsletter: weekly digest of articles, devlog highlights, what shipped. short. no upsells.
no fixed publishing calendar. the goal is “always something interesting recently”, not “post every tuesday.”
the work has been happening for a long time. now there’s a place to watch it happen.
welcome to bradtraversy.dev.