I'm Not an Engineer. I Built 3 RevOps Tools With Claude Code.

I'm not an engineer. I've never shipped production software, I don't have a computer science degree, and I couldn't tell you the difference between a promise and a callback without looking it up. And yet, over the last few months, I built three internal tools that my team uses every week. I built all of them myself, from a terminal window, by describing what I wanted in plain English.

This is the written version, for the RevOps and marketing-ops crowd who keep hearing "just use AI" and want to know what that actually looks like when you're the one doing it.

The tool that made it possible is Claude Code, an AI agent that lives in your terminal. Here's the part that matters: it is not a chat window that hands you code to paste somewhere. You describe the outcome you want, and it writes the files, runs them, reads the errors, and fixes them, while you steer. You stay in the loop the whole time. You just don't have to know the syntax.

The Mental-Model Shift

For years, my instinct when I hit a gap in our stack was the same one most RevOps people have: "I need to stitch together a solution with a no-code tool." Zapier, a spreadsheet, a Notion database, three integrations, and a prayer.

That instinct is now wrong. The new version is: "I'll build a prototype with code this afternoon."

Code stopped being the barrier. The only thing that matters now is knowing what you want, and knowing what you want is the thing RevOps is already great at.

That reframe is the whole talk. Everything below is just proof. Three real builds, each following the same six beats: the problem, the first prompt I typed, how it came together, what actually powers it, what it costs, and where it breaks. Steal the sequence.

One caveat up front, because it matters: these are prototypes, not products. That is the point, not a disclaimer. More on the limits at the end.

Project 1: A Live HubSpot Pipeline Dashboard

The problem. I wanted quarter-to-date pacing, rep performance, and deal-stage breakdowns the way HubSpot won't show them. The usual options are to fight native reporting until you give up, or buy a business-intelligence tool and hire someone to model the data. I didn't want to do either, so I built exactly the views I wanted instead.

The first thing I typed was not a spec. It was closer to: "I want to see how our sales pipeline is doing at a glance. How much we've booked this quarter versus goal, how each rep is tracking, and how many deals are in each stage. Pull it from HubSpot, put it on a simple web page, and I don't want to pay for a BI tool." Notice what's missing: no framework, no database schema, no library choices. You describe the outcome; Claude Code proposes the how.

How it came together was one view at a time. Connect HubSpot with a read-only token and compute QTD counts. Add rep performance, a cohort funnel, and a weighted forecast. Add Stripe for ticket and membership revenue. Reconcile that revenue against what the bookkeeper actually recognizes. Layer in Notion for renewal health. Then clone the whole pattern for a second product line and deploy it. Along the way there were real false starts. For example, the Stripe SDK broke on the host, so Claude swapped it for plain API calls and moved on. That loop, where it hits an error and fixes its own mistake, is what makes the tool work.

What powers it is the surprising part: no AI at runtime. Claude Code wrote the app, but the dashboard itself is a plain web app doing arithmetic on live data from HubSpot, Stripe, and Notion. No model in the loop means it's fast, dependable, and nearly free.

What it costs is roughly $0 to $20 a month.

Where it breaks. There's no login, so anyone with the URL sees live revenue. That's fine for a private link, not for the org. Pipeline names and targets are hardcoded, so a CRM restructure means a code change. It reads live APIs on every load, so it shows current state, not history. When you need governed access, shared metric definitions across a big team, or auditable point-in-time reporting, that's exactly what a real BI tool is for. Use one.

Project 2: An AI Deal-Review Bot

The problem. Before every forecast call, someone on the team opens 30-plus deals one by one to sanity-check them. It's an hour of tedium that happens every single week.

The first thing I typed was, again, just the problem in my own words: "Every Friday before our forecast call, I go through every open deal to figure out which ones are healthy and which are stalling. I want something that does that first pass for me, tells me if each deal is on track, at risk, or in trouble with a quick reason, and drops it in Slack tagging whoever owns the deal."

How it came together is worth sitting with, because the "CRO" doing the grading is not a scoring formula. There's no weighted rubric adding up points. It's a prompt. This exact text runs in production:

I did not write the "act like a CRO" framing. Claude Code proposed it. I described the job; it figured out that the cleanest way to grade a deal was to ask a model to think like the person who'd normally do it.

What powers it is a nice illustration of a point I keep coming back to. Claude Code built the bot, but the part that reads each deal and makes the call runs on GPT-4o. That's not a contradiction; it's just a setting. The builder and the model that runs at execution are two different choices. Want it on Claude instead? One line. HubSpot feeds in the open deals, the model grades each one, and a weekly Slack post tags the owner every Friday.

What it costs is about $5 to $10 a year. Not a typo.

Where it breaks. The first version quietly missed meetings booked through the calendar, so healthy deals looked dead. Here's the lesson worth writing on the wall: the demo can look flawless while the data underneath it is wrong. The color is an opinion, not a verdict; it triages, it doesn't decide. Garbage CRM data in means confident garbage out, because the model will rationalize whatever it's given. And when you need auditable, reproducible numbers for a forecast commit, comp, or a board deck, you want deterministic rules, not a model's judgment.

Project 3: An Automated Content Pipeline

The problem. Every podcast and webinar we produce is a goldmine that used to take hours to repurpose into everything else. At RevOps Co-op, we run webinars monthly and ship a podcast weekly, so that tax adds up fast.

The first thing I typed described the outcome and one crucial constraint: "I have podcast and webinar transcripts in Notion. Build something that reads a transcript and writes a blog post, a LinkedIn post, a Slack post, and a YouTube description, all in our brand voice. Keep the brand voice in a folder of markdown files so I can edit the rules without touching code. Write the results back into Notion and create a draft in our CMS. A human reviews and publishes."

How it came together is different from the first two, because the hard part here isn't the transcript. It's the voice. So we built the voice first. We pointed Claude at everything we'd already published and had it distill a style guide and a set of editorial rules. That "brain" lives in editable markdown files, so marketing can tune the output without ever touching code. A weekly crawler re-reads everything new we publish, so the brain keeps itself current. It's a closed loop.

Roughly half the build was prompt-tuning, and every rule in that brain is scar tissue from a way the model once misbehaved. The instruction that keeps it honest is blunt: factual accuracy is non-negotiable, never fabricate quotes, statistics, or attributions, and every direct quote must use the speaker's actual words from the transcript.

What powers it. A button in Notion kicks it off. Claude Sonnet writes the assets in our voice, and everything lands back in Notion and as a draft in our CMS. You can see the output in the wild on our webinar write-ups and podcast write-ups.

What it costs is cents to dimes per run.

Where it breaks. It's a repurposer, not an author. It voices what's in the transcript; it cannot add net-new insight. Everything ships as a draft, and a human reviews before anything goes live, by design. The guardrails against fabricated quotes are instructions, not verification, so you still fact-check. When you need original thought leadership, or any context where an unverified stat can't survive without a human check first, this isn't the tool.

The Pattern Underneath All Three

Same recipe, three times. Connect the systems you already pay for. Describe the outcome in plain English. Let it run on a schedule. And here's the detail I love: the backend used whatever fit the job. No LLM at all for the dashboard, GPT-4o for the deal bot, and Claude for content. Claude Code was the constant. The model that runs the thing is a choice you get to make, job by job.

So let me be honest about what these are. They're prototypes that earn their keep, not production software, and the difference is real. Security is on you; none of these shipped with real auth. Hardcoded config rots the moment your CRM changes. Models aren't deterministic, which is great for judgment and wrong for numbers of record. And you own the maintenance, because no vendor is on the hook when it breaks at 5pm on a Friday. The skill that actually matters is knowing when a $10-a-month prototype beats a $50K platform, and when it absolutely does not.

What to Build Your First Week

Start read-only and low-stakes. Ship the smallest useful version, then grow it.

1. A single-number dashboard. Pull one metric you check constantly, like QTD bookings or open pipeline, and put it on a page. Add a second metric tomorrow.
2. A weekly digest bot. Have it summarize this week's closed-won, or new leads by source, and post it to Slack every Monday.
3. A repurpose-one-thing script. Turn your last webinar transcript into a LinkedIn post in your voice. One input, one output. Expand later.

The on-ramp is shorter than you think. Install Claude Code (it walks you through the terminal setup), get a read-only API key so you can't break anything while you learn, and ask for the smallest useful thing rather than "build me a platform." When something errors, paste the error straight back in. That loop, where it fixes its own mistakes, is the entire trick.

Code stopped being the barrier. The skill is knowing what you want, and that's your job already. If you want the visual version with the real prompts and screenshots, walk through the slides, then go build the smallest tool your ops team has been waiting for. You can prototype it this afternoon.