The Product We Kept for Ourselves
There's a category of tool that's easy to overlook: the ones that work so well you forget they exist.
For the better part of the past year, Wayne has been running a set of automation workflows in his own stack. Email triage that classifies and sorts his inbox before he opens it. A lead capture setup that logs contacts the moment a form hits. A content repurposing chain that takes a piece of writing and generates five distribution formats before he has to think about it.
None of these were built with the intention of selling them. They were built to solve a problem that kept coming up. And once they worked, they went quiet — which is what good automation is supposed to do. You stop noticing it. That's the whole point.
What Changed
The change came from conversations with small business owners that kept surfacing the same problems.
The bakery owner managing orders through a group text. The consultant whose leads arrived overnight and sat unread until morning. The content creator who published something every two weeks because the repurposing overhead made every post feel expensive.
These weren't abstract use cases. They were specific people with specific situations — and every one of them had an answer in the workflow folder that Wayne had stopped thinking about.
The question became: what would it take to give someone else the tools that were already working for us?
The answer was: more than expected, less than feared.
The Work of Packaging
Building something for yourself is different from building something for someone else. When you built it, you held the context. You knew which field mapped to which variable. You remembered why that three-second delay was there. You had mental shortcuts that substituted for documentation.
Packaging means surfacing all of that. It means writing the setup guide that explains the delay. It means documenting the field mappings. It means testing it against a clean environment — no inherited configurations, no assumptions about what's already in place — and watching it break in ways you didn't predict because you never started from scratch before.
Three workflows. Three weekends-worth of cleanup, documentation, and testing that the original builds hadn't needed. Not because the workflows were complicated, but because making something transferable requires treating it like it was built for someone else.
What We're Claiming, and What We're Not
We're not claiming these templates solve everything. We're claiming they solve specific things, for people with specific setups, and that getting them running should take under 30 minutes.
That constraint — 30 minutes to functional — was the design requirement that shaped the documentation. Every step that took longer than it should have, every field that wasn't obvious, every configuration option that existed but wasn't necessary: those became documentation improvements until the 30-minute bar was cleared.
If it takes longer than that, something in the setup guide is wrong. Wayne's email is on every product page.
The Reason It Matters
The Gumroad store is not the business. It's one revenue stream among several we're building — not the center of the strategy, not the main event.
But it demonstrates something about how FBS works that we think is worth demonstrating: we run on the same systems we offer to others. The email triage workflow is the one running in Wayne's Gmail right now. The lead capture workflow is the one connected to freebeer.ai. The content repurposing template is what generates the distribution drafts for this blog.
We're not selling something we built for a theoretical customer. We're selling something we built for ourselves and then decided to stop keeping to ourselves.
That's a different kind of product. It tends to work differently too.
The n8n workflow templates are available at freebeer.ai. Three to start. More when they earn it.