I was optimizing before I knew what I was trying to produce.

The health score and the product were both “working.” Both generating output. Both doing the thing they were supposed to do on paper. And both were quietly failing in a way that only became obvious when I stopped and asked a question I should’ve asked at the start: what does a good output actually look like here?

The Health Score Problem

I built v1 of our client health scoring model to handle real complexity. Our clients span multiple product tiers — a client on the iPad app operates completely differently from one on the full platform. So I built separate logic by tier, different weights by client type, edge case handling for the ones that didn’t fit. The model got sophisticated. It also became impossible to reason about.

It wasn’t broken in a loud way. It was running, scoring clients, classifying them into quadrants. But when a score looked off, I couldn’t tell you why. Too many moving pieces, too many places the logic could have gone sideways. I spent real time trying to patch it. It didn’t work — because I’d never defined what a trustworthy output looked like before I built the thing.

Scrapped it. Opened a fresh Cursor session with zero reference to v1. The only constraint: if I can’t explain the scoring logic out loud in two minutes, it’s too complex.

V2 came out simpler. Two scores per client — Client Health and Growth Potential — combining into a four-quadrant classification. And one thing v1 never had: every output row tells you how much to trust it. Complete, Partial, or Blocked. V1 produced a spreadsheet full of numbers with no way to know which ones were solid and which ones were guesses. V2 tells you.

Before implementing, I opened a second Cursor window with a different model and had it critique the framework the first session built. Not “find bugs” — critique the design. Does the logic hold for a new client with three months of history? What happens to a client with strong product usage but no support interactions? The two agents went back and forth until the decisions weren’t things I’d assumed — they were things that had survived pressure.

Implementation on a clean spec surfaced data problems, not design problems. We found one source was missing half the activity for iPad-heavy clients — engagement looked low, but they were fine. Found another query silently dropping clients with zero activity instead of scoring them as zeros. Zero and missing are different business states. Neither would’ve surfaced in v1 because v1 was too complex to know what to look for.

63 clients scored. 54 complete, 9 partial. Baseline is live.

The Product Had the Same Problem

Pipeline to Paycheck has paying subscribers now. Real people, real money. That milestone has made the late-night cold outreach — back to my AE roots — paired with the actual product work feel pretty dope. But it almost didn’t happen.

For weeks I’d been running conversion tests. Better copy. Cleaner paywall. Stronger CTA. Flat results.

Then someone told me they wouldn’t spend a single dollar on something that looked like a one-shot vibe coded prompt.

I know what vibe coding is — I’d used the term myself. What I hadn’t connected was that my own product looked exactly like one. Without significant UI/UX work on top of the AI-generated foundation, a vibe coded app looks precisely like what it is. That wasn’t a conversion problem. That was a credibility problem. Completely different lever.

I couldn’t see it myself. I’d built the thing, looked at every screen dozens of times. So I built a workaround.

I opened the Claude Extension and prompted it as a principal product designer at a $10B SaaS company — 15 years shipping enterprise software, Salesforce Lightning, QuickBooks Online, HubSpot’s CRM redesign. Never heard of vibe coding. Only knows what separates a $5K landing page from a $100K enterprise product. Full audit framework: visual hierarchy, enterprise credibility signals, functional UI gaps. Rate the product 1–10 on “does this look like enterprise software” — not “is this good for a side project.”

6.2 out of 10. Fifteen specific callouts.

The summary: “This product is currently in the uncanny valley between ‘impressive side project’ and ‘production SaaS.’ The issues are almost entirely execution-level.”

No founder name anywhere — anonymous products don’t get paid. Every dollar amount displayed in the same color as every button, so nothing meant anything visually. Four different button styles across six tabs. A massive dead zone on the landing page. A paywall that blurred the take-home number before users had seen enough to want it.

None of that would have come from a conversion A/B test. I was optimizing the wrong layer entirely.

The workflow from there: take the audit output, paste it into Claude, have Claude write the Claude Code prompts to ship each fix. Re-run the audit with the same prompt and persona. See what moved. Repeat.

6.2 → 7.8 after credibility fixes — my name in the footer, real testimonials from Reddit, a full demo scenario visible before the paywall.

7.8 → 8.1 after design fixes.

8.1 → 8.8 after a complete color system redesign: teal for actions, green for money, purple for Pro upgrades, no exceptions.

Final re-audit: “Color semantics now match QuickBooks-level clarity.”

I’m a sales guy... I know pipeline stages, comp plans, and what makes a VP of Sales pay attention. I do not know what makes a UI look enterprise-grade versus amateur. The Claude Extension prompted with the right persona does. That’s the unlock: you don’t need to know what you don’t know if you can hire the knowledge through a prompt.

Define the output. Stress-test the framework. Then build.

Ship Log — what I’m building, what broke, and what I learned. New post every week.

Three Builds, One Week

This was one of those weeks where everything moved at once. By Friday I’d shipped a production sales tool, overhauled an executive presentation pipeline with direct CEO feedback, and upgraded a side project from vibe-coded prototype to real product on a real domain.

Two of those are in the hands of real humans right now. One of them has zero users.

All three taught me something different about the same problem: the gap between building something and getting it in front of the people who need it.

Build #1: An Internal Scoping Questionnaire

The ask was simple: take a prospect data-collection questionnaire and make it live so the sales team could send prospects a link.

The vision was zero friction. No login. No email gate. No “create an account to continue.” The company name gets passed as a URL parameter, so the prospect lands directly on question one. Auto-save so they can close the tab and come back a week later. Submissions pipe into Google Sheets. Per-prospect Google Drive folders for file sharing. An admin page so the sales team can generate unique links without asking me.

The architecture was clean on paper: Netlify for static hosting, Google Apps Script as the serverless webhook. Free on both sides. Total infrastructure cost: $0/month.

The HTML was done in an hour. Then reality hit.

Files got swapped during the Netlify upload — both URLs served the admin page instead of the questionnaire. Google Sheets headers pasted as one long string in a single cell. Fetch POST requests to Google Apps Script got silently blocked by CORS. Switching to hidden iframe form submissions fixed the save, but loading saved drafts via GET was also CORS-blocked. JSONP via script tags should have worked but Google’s redirect chain broke the callback. The per-prospect Drive folder feature required navigating iframe sandbox restrictions, authorization scopes, and the realization that HtmlService responses can’t call window.parent across origins.

Nine versions of the Apps Script. An entire afternoon of debugging.

But the system works. Sales generates a link, prospects fill out the questionnaire at their own pace, submissions land in Google Sheets, and folders get created for file sharing. Real prospects are using it right now. The gap between “it works in the editor” and “it works in production” was brutal — but nobody on the sales team cares about my CORS war stories. They care that the link works. And it does.

Build #2: My Executive Biz Review Growth Metrics Were Meaningless

The second build was an EBR pipeline, a system that generates polished executive business review presentations from raw CSV data. Not one-off decks that take eight hours to assemble. A repeatable pipeline that works for any client account.

We’d been experimenting with four different presentation templates, each built by a different prompt in Cursor, each tested against the same multi-entity account, a furniture brand running four divisions on one platform. A Discovery-Led version for new relationships. An Intelligence-Led version heavy on rep data. A Benchmark-Forward version with heatmaps and comparative analytics. A Hybrid that told a narrative.

Each one got something genuinely right. The Discovery version knew how to build rapport. The Intelligence version understood the data. The Benchmark version had the strongest analytical components. The Hybrid had the best story arc. Four templates weren’t four options, they were four experiments that each solved one part of the problem. Consolidation wasn’t about picking a winner. It was about extracting the best organ from each body.

We produced two elite versions: an “Executive Review” for relationship-first conversations with senior leadership, and an “Intelligence Deep-Dive” for operational audiences who want data density.

Then we showed them to the CEO. His feedback wasn’t cosmetic. It was structural.

First thing he flagged: a “+93% month-over-month growth” stat on one of the slides. In the furniture industry, the entire year revolves around trade show cycles. High Point Market in spring and fall, Atlanta Market in January, Las Vegas Market in summer. Presenting month-over-month growth to a furniture executive coming back from market is like telling a retailer their December sales are “surging.” The number is technically real. The framing broadcasts that you don’t understand the world they live in.

He wanted trailing twelve-month context framed against the furniture market calendar. He wanted the breadth metric, a single number that meant nothing to anyone outside our team, decomposed into six activity ladder levels so you could see what reps actually do inside the platform, not just a score. He wanted cohort analysis showing the gap between top and bottom performers with specific suggestions for closing it. Table of contents on everything. Deprecated product references killed everywhere.

Every piece of feedback came down to one principle: the data has to live inside the customer’s mental model, not yours.

The pipeline architecture leveled up too. One mega-prompt trying to read eight CSV files and generate a 17-slide deck was asking for subtle hallucinations in the numbers. The answer: three prompts in sequence. A Brief Generator that processes raw CSVs into validated intermediate documents, then two separate EBR prompts that consume those briefs. The briefs are the validation checkpoint — a human reviews them before anything downstream inherits the numbers. That checkpoint is where you catch the lie before it gets presented to the room.

The system isn’t done. The next step is a behavioral fingerprint query, figuring out what top-performing reps actually do inside the platform so the Activity Ladder mapping is built from real data instead of assumptions. But the architecture is set, the templates are consolidated, and the CEO’s feedback is making every output sharper. That feedback loop is the whole game.

Build #3: The Side Project With Zero Users

And then there’s Pipeline to Paycheck.

Here’s what exists: a SaaS tool that tells sales reps what their pipeline deals are actually worth after federal tax, state tax, FICA, 401k, and insurance deductions. Production-grade tax engine validated against real paystubs. Goal tracking with image uploads — attach a photo of the actual Zillow listing you’re saving for. Monthly forecast charts. A YNAB-inspired “every dollar has a job” allocation system. Three persona flows. A live Stripe button at $29.

It started on a pipeline-to-paycheck.vercel.app URL with full vibe-coded energy. Functional, fast, clearly built in a weekend. Which is fine when you’re prototyping. It’s a problem when you’re asking someone to trust your tool with their compensation data.

Peer feedback cracked it open. Friends and colleagues weren’t reacting to the features, they were reacting to the feel. The app worked, but it didn’t feel like something worth paying for. So I used the Claude browser extension and Cursor to rebuild the experience from the outside in. Bought pipelinetopaycheck.com. Overhauled the landing page. Tightened the UI. Made the whole thing feel like a product someone built on purpose, not something someone stayed up too late making.

Same tax engine underneath. Same calculations. Completely different first impression.

Here’s what still doesn’t exist: a single user who isn’t me.

The Pattern I Can’t Ignore

The prospect questionnaire has real users on day one because a team was waiting for it. The EBR pipeline gets sharper every cycle because the CEO is in the room breaking my assumptions. Both builds have feedback loops with real humans pushing on the output.

Pipeline to Paycheck has me. Staring at my own dashboard. Convincing myself the headers need to be sentence case before I can show anyone.

The contrast is hard to ignore. The work builds taught me what happens when real people push on your work: it gets better fast, in ways you wouldn’t have predicted. The side project is teaching me what happens when that loop doesn’t exist: you optimize for your own taste and call it progress.

The 2,000-Person Trap

So how do I get Pipeline to Paycheck in front of real users?

Sitting in my contacts: 2,000 PE and VC professionals from previous roles. Warm-ish. Reachable in about fifteen minutes. The gravitational pull was enormous — one blast, 2,000 inboxes, done. I could call that a “launch.”

The product I built? A tool for BDRs and AEs. The tagline on the landing page is literally “Because your manager sure as hell won’t do this math for you.”

Two thousand investors. A product for individual sales reps.

I was about to measure whether my old contacts were polite enough to subscribe to a Substack and call it product validation.

The instinct makes sense on the surface. You have contacts. Contacts equal distribution. Distribution equals traction. But the logic breaks at step one: the contacts have to actually want the thing. A PE associate isn’t wondering what a $50K deal puts in their bank account after taxes. They might subscribe out of curiosity or professional politeness, but that tells me nothing about whether sales reps — the people who’d actually use this daily — would pay $29 for it.

Two Tracks, Run in Parallel

Once I mapped it honestly, the fix was obvious. I was trying to serve two completely different audiences through one channel because it felt efficient. It wasn’t.

Track 1: Ship Log (Substack) → Operator/founder audience. Building-in-public content about shipping products with AI, architecture decisions, the unglamorous reality of building on the side while doing real work during the day. These people care about the building story — the EBR system, the questionnaire, the side project, all of it. If the Substack resonates, it becomes a genuine operator following that doubles as a fundraising network later.

Track 2: Pipeline to Paycheck → Direct to reps. Completely separate channel, completely separate tactics, completely separate success metrics. No email blasts. No hoping investors forward it to portfolio companies. Direct-to-practitioner distribution through LinkedIn creator seeding — finding mid-tier creators (5,000-30,000 followers) whose audiences are full of the AEs and BDRs who’d actually use this tool.

The two tracks reinforce each other — Ship Log features Pipeline to Paycheck as a project, creating a natural bridge — but neither depends on the other.

The Honest Part

I have a day job. A real one. This week alone I deployed a production sales tool from scratch and helped architect an EBR system that the CEO is personally shaping. The work is substantive and I’m invested in it. The side project doesn’t get nights-and-weekends energy if the day work suffers.

But that’s also the excuse that lets you keep building instead of distributing. “I’ll do outreach when things slow down at work” is the solo founder’s version of “I’ll start the diet on Monday.” Things don’t slow down. You either carve out the time or you have a really nice app with a really nice domain that nobody visits.

The building phase is over. The product works. The domain is bought. The Stripe button is live. I went from vibe-coded prototype to something I’d actually show a stranger. Every additional hour spent polishing is an hour not spent finding out whether anyone cares.

The 2,000 contacts aren’t going anywhere — and they become dramatically more valuable later, when I can email “50 active users, 5 paying customers, here’s what I’ve learned” instead of “subscribe to my new thing.”

This week, I send the first DMs. I find the first creators. I put the URL in front of people who actually calculate commissions for a living and see what happens.

Two of this week’s builds already have feedback loops. The third one is about to get one.

Three builds. One week. Two in production with real users. One with zero. That’s the one that matters most right now — because it’s the one that still needs to prove it should exist.

I built a system that hits 9 different tools in a single pass — CRM, billing, product usage, call recordings, support tickets — and gives me a finished deliverable in about 30 seconds. QBR packages, onboarding assessments, meeting prep, support analysis, weekly pipeline reports.

The tool at the center of it? A code editor.

Cursor is a code editor. That’s what it’s built for. Developers use it to write and review code with AI baked in.

I’m not a developer. I’m a salesperson at heart.

And Cursor has become the single most important tool in my stack; not because I’m writing code, but because it’s the only place where all my systems can talk to each other at the same time.

The Setup

Cursor sits in the middle, connected to everything through MCP (Model Context Protocol): BigQuery for quantitative data, HubSpot for CRM, Mixpanel for product behavioral signals, Fathom for call recordings, Help Scout for support patterns, Jira for project tracking, Notion for docs and wiki, our Admin Console for order and revenue data, and GitHub for codebase context. The whole thing runs in the cloud through Windmill so it’s not just living on my laptop.

That’s 9 systems, one connection layer, running in the cloud. Every GTM team has some version of this problem — data lives in a dozen places and nobody has a unified view. The normal answer is dashboards, or a BI tool, or hiring a RevOps person to spend a week stitching it together manually. Or paying a consultant.

I just ask Cursor.

What This Actually Looks Like Day to Day

“Build me a QBR package for XYZ account.”

One prompt. It pulls org data, queries BigQuery for product usage, grabs revenue from the Admin Console, runs benchmarks. Output is a three-part executive package — sales effectiveness, instance health, rep performance — plus a composite health score. It flagged that 80% of the account’s customers were inactive, representing an $8.2M expansion opportunity. Data pull to finished deliverable. One session. Not days of spreadsheet assembly.

“Run a stage-gated assessment on these 6 onboarding clients.”

It queries four systems simultaneously — production database for products and orders, BigQuery for iPad activity, Fathom for recent call recordings, Help Scout for support tickets. Comes back with per-client readiness scores. One client scored 91% ready. Another scored 27% — 99 days of no contact, 346 days of stale data. Effectively abandoned and nobody knew.

But the best part: it caught a contradiction. One client showed “inactive” in the database but had 5 Fathom calls and 10 support tickets in the last two weeks. Clearly active — the database was just wrong. That cross-system validation is something no single dashboard gives you.

“Prep me for my meeting with Clarence — they have two entities.”

It pulled billing from Stripe, rep-level usage from Mixpanel, support history from Help Scout, order data from the Admin Console. Found that one rep accounted for 70% of all orders across 3 devices. Found that the second entity was processing $13.59M in order revenue but had no Sales Portal subscription — a $395/mo upsell just sitting there. I walked into that meeting with a user-concentration risk to discuss and a concrete expansion play with dollar amounts attached.

“Analyze our L1 support tickets from the last 180 days.”

349 tickets categorized and broken down. User management was 35% of volume. Password resets alone were 37 tickets — 11 of those were voicemails from people who literally couldn’t log in. It calculated that self-service password reset plus a few targeted help articles could eliminate 83 tickets, a 24% reduction. That became the business case for building self-service features. Not a hunch. A number.

“Generate my Sales Week-Ahead report.”

HubSpot for pipeline, Fathom for the last 30 days of calls. Output: $X total pipeline, stalled deals flagged, and for each upcoming discovery call a full SPICED framework prep with must-ask questions. From the call transcripts it pulled voice-of-customer themes… “manual data entry” mentioned 12 times, “spreadsheets” mentioned 11 times, competitor mentions ranked. Even gave me a coaching note. That runs in about 30 seconds.

Why This Matters

None of these are things you couldn’t do before. You could absolutely build a QBR package, or analyze support tickets, or prep for a meeting. It just took days. Or you’d pay someone to do it.

The shift isn’t capability. It’s speed and cross-system visibility. Every one of those examples hit 3-4 different data sources in a single pass. The insights that actually mattered — the abandoned client, the database contradiction, the upsell opportunity, the user concentration risk — all came from combining data across systems. They don’t exist in any one tool.

A dashboard shows you what you asked it to show you. This shows you what you didn’t think to ask.

The Thing Nobody Tells You Though

It’s not magic. Getting all these systems connected took real work. And I’ve learned the hard way that the session that built something is the worst place to debug it — the model carries your assumptions with it. So I build in one session, then hand it to a fresh one to pressure-test. Fresh context catches what inherited context can’t.

But once the pipes are connected? The question stops being “can we get this data?” and starts being “what do we want to know?” That’s a fundamentally different way to run GTM.

Three weeks of consultant work. Thirty minutes.

This is Ship Log — what I’m building, what broke, and what I learned. New post every week.