Nobody gives you real feedback on something they got for free. Somebody on the AMA offered to be a guinea pig for something I'm building, and it got me thinking about the order I actually use. The best guinea pigs are, first, my team. Second, my Insiders. Third, people who are actually paying me. And you don't really get the real feedback until people are paying you money. That's what I learned launching Consulti, our cold email lead gen software. We had our team demo it. Then we had our Insiders demo it. I got pretty solid feedback out of both of those rounds. Then people started paying me for it, and man, it was a whole different level of feedback. My guess at why: a free tester will tell you what's broken, and a paying customer will tell you what's broken in the exact workflow they needed to finish today. Free testers aren't lazy, they're just not under the same pressure. Someone testing as a favor pokes at it with whatever part of their day is already flexible. Someone who paid runs it straight into their actual constraints on day one, and their tolerance for a rough edge is zero. I'm not telling you to skip the friendly rounds. I still run them. My staff is demoing and debugging the next thing I'm building right now, and that round will catch plenty. Just don't read a clean internal test as evidence that you're ready. Read it as evidence that you removed the obvious problems. The painful ones are still out there, waiting for somebody with a credit card. Which group are you testing with right now?

It is dangerously easy to import dozens of pre-built n8n workflows and agent skills without ever shipping a single paid client system. You feel productive loading up GitHub repos and testing triggers, but turning those raw automations into a repeatable, deliverable service is where everything tends to stall out. Having the backend blueprints solves the technical hurdle, but packaging and deploying them consistently is another battle entirely. For anyone building out their agency offer here, where does the transition from testing templates to delivering for real clients usually break down?

I've been going back and forth on an architecture question for weeks and I'd like to hear how you handle it. My current setup: - Vault (Obsidian, Git repo, also a Claude Code project): processes, SOPs, decisions, strategy, research. It's the "brain" of the business, and the agents work from it. - Dashboard (FastAPI + React + Postgres, hosted on Vercel): numbers, P&L, team KPIs, CRM-style modules, internal tools. They live in separate repos. The vault still runs locally on my Mac, but it's moving to a VPS soon. The idea I can't let go of: Put both in one repo. The vault would be the "backend" (knowledge, rules, processes) and the dashboard the "frontend" everyone uses online, including the team. What speaks for it: - One place, one version, no "two sources of truth" - Claude Code sees the knowledge and the code at the same time and can change both together - Usable online instead of being tied to my laptop - The team works through one interface instead of Obsidian + dashboard + Notion - Syncing between the dashboard and the vault stops being a separate project What speaks against it (and why I've held off so far): - They hold two very different kinds of data: text and knowledge on one side, structured numbers on the other. Those usually belong in different stores. - The vault changes constantly because agents write to it. In the same repo, every note change could trigger a deploy. - Access control: not everyone who uses the dashboard should see strategy and decision notes, and the reverse is true too. - Vercel is serverless. You can't just host a writable Markdown vault there, so you need your own server or a database anyway. - Coupling: if one breaks, the other goes down with it. The alternative would be to keep them separate, move the vault to a VPS and connect the two via API/MCP. They'd be connected without being merged. My questions for you: 1. Do you keep your knowledge base (docs/SOPs/vault) and your internal tools in the same repo or separately? 2. If you've made your vault usable online, how did you do it? VPS, Git sync, database, MCP, a custom frontend? 3. How do you control who on the team can see what? 4. Has anyone merged the two and regretted it later, or the other way around?

Finding them one company at a time in Apollo works, it is just slow enough that the list will not be done before Q4 is over. I assumed having Apollo mcp to Claude would suffice, but it hasn't. So I am trying to understand how people structure the work optimally: 1) Where does the manual part sit in your process? Up front choosing who to look for, at the end reviewing what came back, or both? 2) How do you decide which contacts are worth revealing and which are not, before the credits go out? 3) What do you do when a company is small and the titles you expect are not there? 4) How to speed up the process without burning through your tokens (Claude), credits (Apollo) and most importantly your time? If you have run this on a real list, even a rough outline of the steps would help.

Been playing around with Claude quite a bit lately and have been building some pretty good tools to help me in my insurance sales role, but I’ve intentionally stayed away from Claude code. Im not a developer and it can be a little overwhelming. Thinking about my next thing and possibly starting a RevOps biz, so decided it’s time to get with the program and really learn this stuff. Jays content is great— he’s my primary guru for lead gen, so I’m assuming this is going to be just as thorough and clear.