Hello {{First name|Predictable Revenue community}},

Book update: An audible review from the end of the year slipped my radar but most accurately sums up my startup experience, struggle and study. Check out the product of that experience in The Terrifying Art of Finding Customers.

Live talk: Next week I’ll be discussing the Customer Development Funnel with Alex Shartsis from the Seed to Sequoia newsletter, register here.

Onto the newsletter…

I've been vibe coding for a few months now. And I want to be clear about something: I am not an engineer. I can't read every line of code and tell you exactly what's happening. But I can get the job done.

I started in locked-down environments like Lovable and Replit. Then I moved to Claude Code. And while I'm still finding my feet, the productivity gain from that switch has been huge. It feels magical, honestly, because six months ago I couldn't produce anything resembling functional software. Now I'm shipping things that work.

They're not elegant. They wouldn't scale. A real engineer would probably look at my code the way a chef looks at a microwave dinner. But for what I need, it works. And "works" is a meaningful bar to clear when the alternative was "doesn't exist."

Here's what I've been building. I revived Athlon, an old fitness gaming startup of mine that died in 2023. It was built to encourage exercise habit formation through gaming mechanics. I wouldn't call it fully alive yet, but it's functioning for users in a way it couldn't before. That's a win. 

I'm building my own AI CRM. Not because I think it's going to be a commercial success, but because I wanted to experiment with knowledge graphs, with Neo4j, with tools I'd read about for years but couldn't touch because I didn't speak the language. I've got a meeting bot that grabs my Zoom recordings and transcripts, saves them to Google Drive, and feeds them into the CRM. Is it perfect? No. Is it cool? Absolutely. Should I have bought Clarify or Lightfield instead? Probably. 

I've also built vclist.co, a place for founders to find their best future investors. It had its first customer land last month. Again, not something I could have built a year ago. But the tools caught up to my ambition, and now it exists.

And here's where it gets interesting. I'm not actually spending less money on software. When I add up my Claude Code credits, my Lovable subscription, my Anthropic API usage, my Clay credits, that month I spent a grand on Manus, it's probably about the same as what I was paying for Salesforce and HubSpot combined. I've already canceled both, by the way.

But here's the difference: my productivity per dollar has gone way up. Same spend, dramatically more output. That's the number that matters.

So what happens when there are more people like me? People who can't code but can build things that work?

I think it changes the build vs. buy equation in a fundamental way. And I don't think the SaaS industry is ready for it.

For the last 20 years, SaaS has had a golden run. Building software was expensive. First you needed to buy the hardware, then you needed to rent the infrastructure, then you needed engineers who understood the dev tooling, then you needed to actually write the software. The barrier to entry was high, which meant if someone built a tool that solved your problem, buying it was almost always the rational choice.

That math is shifting. Not for everything, not overnight. But it's shifting.

I was talking to Michel Feaster about this recently, and she made a point that really stuck with me. She said we're going to see a renaissance of internal IT operations. The last two decades pushed power outward, toward SaaS vendors. Companies became dependent on external tools for everything. But as building gets easier, that power starts flowing back inside the organization. Internal ops teams are going to take a more central role again.

And she's right. I can already see it in my own behavior. I'm building things that replace software I used to buy. Not all of it. But the stuff that was thin on value and high on price? That's the software that's in trouble.

The complicated stuff is probably safe for now. I feel bad for whoever decides to vibe code their own ERP system. They're either going to be the smartest person in the world or have the absolute worst time. Same goes for accounting software, security infrastructure, anything with deep compliance requirements. Those categories have real complexity that protects them.

But marketing tools? GTM tech? A lot of the lighter-weight SaaS that charges $200 a month for something a motivated operator could build in a weekend? That's where the pressure is going to show up first. I love Clay but as soon as I can figure out how to recreate Claygent, I’m gone. 

Here's the part nobody's talking about yet. When amateurs like me build trash internal tools, we create problems. Security problems. Compliance problems. Documentation problems.

My buddy Jesse likes to remind me: there's nothing more permanent than a temporary solution. Usually right after I show him something janky I've built.

Think about what happens inside a company when five different people vibe code five different internal tools. None of them are professional engineers. None of them documented their build process or committed code properly. The tools work, but barely. Then two of those people leave. Who owns those tools now? Does the software get sunset? Rebuilt? Does anyone even know how it works?

This is going to be a real thing. We're going to end up with all these janky scripts and apps that companies rely on, built by amateurs, maintained by nobody. And somebody's going to need to keep them alive.

Just like Clay created the "GTM Engineer" as a role, I think we're going to see something like an internal build-ops person emerge. Someone who's part old-school IT admin, part DevOps, part vibe code wrangler. Their job is going to be maintaining the growing pile of internal tools that non-engineers built and then moved on from. To this person, I’m sorry for my crappy code. Yes, I know Git, no I didn’t leave you anything helpful. 

Marc Andreessen made a point on Lenny's podcast recently that stuck with me. He said we've actually been in a period of very slow technological change in the economy for the last 50 years, and that AI is arriving right as birth rates are declining globally. His argument is that we actually need AI to keep the economy from shrinking, not the other way around.

I think he's right. And I think the build vs. buy shift is one of the ways that plays out at the company level. AI isn't just going to replace workers. It's going to make the remaining workers wildly more productive. My own experience is proof of that. Same budget, dramatically more output.

So who benefits most? I think it's small and mid-sized companies. Enterprises have the economic incentive to build internally, but the organizational complexity makes it nearly impossible to get buy-in for ripping out something like Salesforce. Startups and small teams, though? We're free to run and gun. We can experiment, rebuild, iterate without a procurement process or a change management committee.

The SaaS companies that survive this shift will be the ones solving genuinely hard problems, the ones where the build vs. buy math still favours buying even when building is cheap. The rest are going to feel the squeeze.

How much squeeze, and how fast? That's the part I'm still figuring out.

Collin

PS - if you have questions or just want further context, come hang out with Alex and I for an hour. We’ll be talking about the Customer Development Funnel. Register here.