Pragmatic AI with Matt Stauffer

The Pragmatic AI Podcast is sponsored by Tighten.

T-I-G-H-T-E-N.

We will take your AI ideas, prototypes, or even vibe-coded apps,

and we'll take them to production.

Scalable and secure. Check us out at tighten.com.

All right.

Welcome back to Pragmatic AI, where we talk about using AI in the real world.

What works, how to use it well, and when it causes more harm than good, practical tools
and real trade-offs for builders and business leaders.

My guest today is my friend Brian Castle, founder of Builder Methods.

Brian, would you mind saying hi?

And if anybody doesn't know who you are or what you're about, can you kind of talk about
your business?

Yeah, hello.

um Matt, great to connect with you again.

I know it's been a couple of years.

I think our beards are longer.

Mine's a bit grayer than last time we hung out.

yeah.

Cool.

So yeah, I'm excited to get into it.

um Yeah, these days I run buildermethods.com.

And I've been making a lot of videos on YouTube talking about AI.

It's the thing that.

thing.

Yeah.

Yep.

yeah, that's, and I'm building a, I mean, I'm building more, I've been building for 20
years, but I feel like I've been building more tooling and systems and agents in the last

like three to six months than I did in the last 10 years.

It's just unreal.

So can't wait to get into it.

things I told you ahead of time was I've had several people who consider themselves career
developer educators.

And not to say that they're not fascinating conversations, but one of the things that I
want us to go into the fact is while you happen to be a developer educator, now that's not

really your history.

And I don't even know if you'd necessarily identify as an educator.

Like, do you think of yourself as an educator or you think of yourself as a builder who
happens to be kind of bringing people along as you go?

It's a really good question.

I actually do identify as a educator in some way.

And this goes back throughout my whole career, actually.

I haven't built major businesses as training companies or educational companies.

um ever since I've actually been on my own, which is going on 20 years now,

Even from the very early days, I was always blogging and podcasting and building in public
and sharing.

But I also used to dabble.

I started out like back, this is like back in like 2010 or so I wrote like an ebook about
my design work.

And then in the 2014 to 2020 period, I created and sold a course called the Productize
course.

And that was all about productized services.

And that

That did pretty well.

Like it was a significant line of business, but that was never my primary business.

That was always like a side hustle to what I was actually building, whether it was like,
you know, and I've gone through built and bootstrapped and exited and rebuilt multiple

businesses over that time span, a bunch of SaaS products, some productized service, like
agency type stuff, uh and that course business.

But then that was like about 10 years ago.

And then I really,

was deep into SaaS for the last like five, like seven, eight years.

And I sort of stepped back from the actual teaching and even content stuff like blogging
and video stuff I really didn't do much of.

I always podcasted just for fun with Jordan and now with Justin and Jordan.

But this year, starting last year in 2025, when I kind of, I went through a period of
like,

my own identity as a business owner and entrepreneur and like, am I a SaaS person anymore?

Should I come back to my roots as an educator, as a video content creator?

And that stuff's really started to click for me in 2025 when I started Builder Methods,
you know?

now, so we're here in April, 2026, Builder Methods is about eight months in, eight or nine
months in as like, as an actual business and brand and everything.

And it feels great because I always felt like this is part of this whole business
strategy, besides like the AI stuff and that whole wave.

uh For me personally, it's like leaning back into my actual strengths, which I think are
communicating and uh like simplifying technical concepts and uh helping people build,

mean, while actively being a builder myself still today, you know?

Yeah, I watched a couple of your videos to prep and one of them I watched was your very
popular how I set up my Mac minis for open claw and one of the top results was someone

saying it's so nice to find somebody who actually understands the technology teaching the
technology which would make you think that oh I really appreciate the fact that you're

being hyper technical but it was clear from both from watching you and then also from the
other comments but there's also this ability to deeply understand and then also

synthesize.

that is definitely like a core strength of yours.

And it's so funny, so you mentioned a couple terms here, I just wanna make sure everyone
understands.

So SaaS is software as a service, so basically if somebody were to build a piece of
software on the internet and then charge you subscription to use it, so that's SaaS.

Bootstrap means that you funded it yourself rather than taking venture capital funding.

And then there's one other term, I don't remember what it was, but we'll get to it.

you, oh, build out loud, and that was one of the things, or build in public.

A lot of people in our world, for those who don't know, have talked about the fact that um
if you are building one of these things yourself, you're not gonna have $50 million to

pour into marketing like a lot of venture capital.

You're not gonna have billboards everywhere in Silicon Valley.

So you have to have the ability for people to know who you are and what you're building
somehow.

And one of the ways to do that is just to kind of share on the internet when you're
building things.

um

And so, Brian, you historically have built been someone and so I know that you mentioned
I'm like, yeah, you are an educator, but I just have always thought of you as a builder

who just builds in public.

You just kind of share what you're working on.

um Yeah, please.

minute, because I've always felt compelled to build in public literally since from like
the first year that I was a freelancer.

When I went out as a freelancer web designer, this was in 2008, the gray hairs are showing
now.

Like even from that first year, all I was doing was freelance websites, but I started
blogging.

I started writing a newsletter.

Like, why am I even talking about what I'm working on?

And then I started podcasting with different people and then, and, just sharing and
tweeting.

And to me, the term building in public and the interest in doing it has always been, Hey,
let me show you some, some of my projects, but I am more importantly, I'm hungry to see

what you're, what everyone else is working on.

Like the early days of Twitter.

uh Remember like Dribble, the design site, like the whole concept of these types of sites
is like designers and developers and builders.

showing their actual work and their creative decisions behind their work and uh the final
product and the impetus behind why they do things.

That's always fascinated to me.

Those are the types of podcasts I like to listen to from my peers, my fellow professionals
in this industry.

I like to go to conferences and learn from people who are building.

And then in more recent years, the term build in public started to get

I don't know, like co-opted from this marketing state, like people sharing their MRR
graphs and like revenue numbers and like supposedly that's building in public.

And to me, like I've actually never really shared my revenue numbers publicly.

It's not interesting to me.

I feel, I don't feel comfortable doing that all the time.

I'll give indications of how my business is going, but it's not, not gonna, I don't think
that sharing a MRR graph in a tweet is building in public.

Like that's just bragging about your revenue.

um

I'm much more interested in the actual building and seeing what you're building and why
and how.

so that's my little rant on building public.

core concept of sharing your revenue may or may not be an issue, but it's at least for me,
it's the there is a it's all the hustle mindset people.

Like there's a it feels like there's a playbook of what your relationship to your public
image looks like.

And you're just using this business you're theoretically building.

And it always feels a little fake.

You're using these finance numbers as just a part of a

marketing campaign for your own persona that doesn't feel honest, maybe?

It doesn't feel honest to who you are.

It's like just a, it's just a trick, you know?

Yeah.

And I mean, like, don't get me wrong.

Like definitely the fact that I have built in public all these years, I would say,
especially through podcasting.

I did bootstrap web with Jordan for like 10 years.

And now Jordan's back on the podcast with Justin and the three of us are doing it.

Like that is definitely probably the main form of how I've built in public, sharing real
time updates on what we're building and why.

And that has had incredible benefits throughout my career.

All sorts, like not just like listeners coming in as clients and customers and that
happens.

Definitely referrals.

People recommend my products because they know me they're invested in my, in my journey.

People I work with or partner, I get invited on podcasts.

Like I get invited to speak.

Like all that stuff has business benefits for sure.

but then also part of me has always been a little bit uncomfortable with, with that.

Like the fact that some

portion of my leads and customers for all the businesses that I've ever done have always
come through the build in public channel, right?

um And that has always made me uncomfortable and increasingly over the years more and more
uncomfortable because while some of them are like real customers and they get real value,

there's always some element of like, well, they just sort of like me or they're invested
in the story.

So they don't really have that product market fit.

um

And so I'm much more, I've always been much more interested in trying to build and release
products and develop marketing channels where they don't know me at all.

And actually that's one of the things that I'm, like YouTube is interesting now because I
would say 99 % of the people who are watching me on YouTube, they never,

have heard of my podcast, they probably don't follow me on Twitter, they don't know any of
my history of all the previous businesses that I've done, they're just discovering me

today on YouTube.

feels like hard mode.

Like to be, you're like, Hey, you know what?

have this established audience.

I've got, I've got a newsletter subscriber list, a Twitter follower list.

I've established reputation and I see the value in it, but I'm like, it's scary, right?

Like to say, you know what?

I'm going to throw all that away and I'm going to go to this entirely new space.

Was it an intentional decision to do that?

Or is it sort of like, well, I'm just, it's how YouTube has panned out.

Yeah, I mean, I wouldn't say I'm throwing it away.

don't, I don't turn that stuff away, but I would say that, first of all, like all the
years that I was doing SaaS, like the audience doesn't really help with that.

Like of all the business models, uh, like there are, there are some benefits, like I said,
like there's some network benefits.

There's some like, you know, around the edges, it helps.

Um, but it's not an actual customer, uh, pipeline.

Right, because the people who are interested in what you're building are usually not the
people who want to use what you're building.

So you've got a lot of followers who are not going to pay you any money.

yeah, it is very helpful in the very beginning to like get some initial traction and get
some feedback and stuff like that.

But, so I did like going back 10 years when I was doing productized service stuff, I had
some, some audience from that, but it didn't really translate into SaaS marketing success.

And so then my audience sort of stagnated there for like five, 10 years.

And then this year with YouTube,

The YouTube channel is like the first thing for me that has really clicked as a channel
where I know that I can uh reach and get exposure to new strangers who've never heard of

me before.

uh And they're resonating with the ideas that I'm talking about.

uh And the other thing that I like about it is that like it's, it is still obviously like
an audience channel, but it's also a creative channel.

Like I'm really into the creativity of...

scripting and coming up with YouTube concepts and communicating on camera.

that to me is, art form is probably the wrong word, but like a creative outlet that's
honest, like from a marketing standpoint, you know?

Cause I, all the other marketing stuff that I've ever done, whether it's ads or like SEO
or, you know, um cold outreach, like.

here and there drips of things that might work here and there, but like nothing has just
been a home run um and this thing sort of clicked.

Yeah.

That's a perfect transition.

Let's talk about this thing.

So we've talked about kind of in the past, you've built SaaS you have done some kind of
developer, I wouldn't call it developer education in part because a lot of your target

audience are business founders more than they are developers.

So you've done some education stuff.

You've podcasted, you've made some courses.

um And at some point over the last couple of years, you created Builder Methods and you
created this YouTube channel, Builder Methods, and there's a product and there's YouTube

channel.

Like, can you talk about what was the story of creating it and what is it today?

Yeah, so if you're new to it, so buildermethods.com is essentially a membership oh that
like I sell one product membership called Builder Methods Pro.

m It's an annual subscription to be a member and what you get is a library of video course
content on building with AI.

And there's also some courses in there on uh setting up and deploying agents in your
business.

um Then there's a really active community.

Right now we've got like hundreds of

of active builders uh in uh the community.

uh I've also been doing these live sessions.

uh Some are sort of workshops.

A lot of them are just like Q and A open, like what are we building?

Like who's working on what?

Let's share notes, ask questions.

uh And something that I'm starting to develop right now as another benefit is this idea of
starter kits.

uh actual products, like applications that I design and uh

and plan out from a product roadmap standpoint, creating a spec and PRD, uh pre-written
prompts, like all these things to get you started to build the same product yourself.

But the nice thing is that you get to build it yourself, just using my starting point.

I'll show you how I would build it on video.

You can take it and run with it and iterate it and customize, going in a different
direction with it.

And so there's a collection of these app starter kits for all these common different...

tools that I'm building.

uh All that is kind of packed into the Builder Methods Pro membership.

uh I mean, on the free side of things, we've got the YouTube channel, I do a weekly
newsletter, uh you know, sharing.

I wouldn't call it like a newsfeed of like every single drop.

There's gonna be a release from me.

um Sometimes I do talk about like new things from Claude Code or whatever it might be.

But uh yeah, it's really just my take on.

what's interesting, what's working right now as a builder.

I really focus on workflow.

I focus on the transition.

We're all in this super fast transition.

There's a lot of anxiety around that on multiple different levels.

The speed is, I've never seen anything in this industry move so quickly before.

And so there's just a lot of like grappling with that.

Like that's just a big theme in every.

in every video, every piece of content that I'm making here through builder methods, it's
tackling this question of like, okay, this stuff is shifting.

Now, what does this mean for us as builders?

What should we pay attention to?

Yeah.

you think of builders.

Do you mean people building?

Bootstrap companies is that building sass like what is building mean?

uh It's a mix inside my membership right now.

And it's something that I'm thinking right now about like shifting who I'm speaking to.

um But I would say my audience is split between, there's a lot of just builder, let me
step back.

So when I started Builder Methods last year, I started with the intention of speaking to
the professional developer.

um So someone who's been around for years built,

know, handwriting their code and they need to adapt and start to adopt like Claude code
and all these other tools in their workflow.

That has started to shift in the last few months.

And I've always started to attract other business owners who are not developers, not
technical, but they are becoming legitimately technical now.

these are not, the term vibe coding doesn't really do them justice because they are

They are systems minded.

They operationalize like pretty complex processes in their business.

They just never hand wrote code before.

um And now they have a very legit um business need and an interest and a legit capability
to come in and learn how to use Claude code at an actual professional level.

And that's what I'm trying to help them do.

And I'm receiving a lot of people coming in in that.

in that path where it's like somebody who runs like a real estate office and they need to
implement some agents in their processes or someone who has a complex business need and

they wanna build like an internal tool just for their operations.

So building of internal tools is a really big need.

uh And now like more recently, I'm really interested in this like interplay of agents and
custom tools.

And I think a lot of business owners like they don't necessarily know or care whether

their problem is solved with a custom app, like a custom Rails app or Laravel app, or if
their problem is solved with just using Claude or Claude Cowork or Claude Code, or some

mix of skills or an OpenClaw agent, or maybe all three of these interact in some way with
their human team.

Like all this stuff is getting mixed together.

They just know that we can scale, we can move faster, we can build systems in ways that we
couldn't before.

So.

There's a lot in there and right now I'm actually making this shift in builder methods to
focus more on the, I say a builder, you don't have to be a developer, you don't have to

identify as a developer anymore.

uh You're just a builder.

uh I should say there is also a segment of people who wanna build uh a product to bring to
market, like maybe a new SaaS tool or some other product.

And that's interesting too because,

there are all these people who have like an inroad or have a preexisting audience with
some niche industry or vertical.

And before they would have had to hire a developer or raise a lot of investment or spend
years learning how to code themselves.

You don't have to do all that stuff.

And you can be a step above a vibe coder who can maybe whip up uh a play toy in a weekend.

uh There are...

people like actual builders, like business owners who are like taking this seriously,
building stuff every day, spending weeks and really perfecting their craft um and building

something real, you know?

Yeah.

So I'm hearing uh there was a little bit of a pivot, but right now it is people who are
building software to help businesses or to create businesses, whether or not they're

actually historically software developers.

Is it all AI focused?

Would you say Builder Methods is universally AI or is it sort of like it's for building
and AI happens to be an implementation detail?

Yeah, it's since day one, it's been focused on AI.

And yeah, I would say that's like a core focus.

Like if you're building with AI, Builder Methods is the place.

Like you did talk about like other like developer training companies and boot camps out
there over the years.

I think Builder Methods started in the middle of 2025 at a time where like those started
to become

probably less relevant and builder methods as a entity and a brand started showing up as
like, if you're learning how to build with AI, this is the premise for builder methods.

um

wants to learn with AI, mean, one of the things I've talked to multiple people on the
podcast about before is how do we, as people who've historically trained developers, how

to write code, what does it look like for us to pivot so we're training developers other
things, and how do we potentially bring in non-developers?

So I think that the dreams of those groups are not to become irrelevant, but to pivot to
doing potentially similar to what you're doing.

um

I'd be curious as you are educating non-developers about development topics, uh how are
you able to know what's the right decision in terms of how much development do they need

to learn versus how much should they offload?

When should a person just be building with an agent versus when open claw?

Is that trial and error?

Do you have a small group that you're doing one-on-one?

How do you even figure out answers to those questions?

Yeah, it's a good question.

um Yeah, I get a lot of questions from members in the community.

Actually, right now I'm in the process of rolling out a new course inside of Builder
Methods Pro called Become the Builder.

And I'm literally teaching my go-to tech stack for when I build.

So this is for building apps.

um I've always been a Rails developer.

I now use Rails and Inertia and React.

That's my go-to stack.

But this course is for people who want to be able to build exactly how I build with my
stack.

But you don't need to learn how to hand write Ruby code or Rails code or JavaScript.

You do need to know what these pieces are.

Why React?

Why Rails for me?

What is a database?

how do these things interact?

What does it mean to like deploy an app?

Like how do we use GitHub?

What's the workflow here?

And even if we're asking Claude Code to do a lot of these motions most of the time, we
still need to know what's happening and why.

uh And this is how you, you know, maybe you've played with lovable or replet or one of
these, but this is how you transition to how the real pros are actually building is

knowing how to put these tools together.

And then over time, as you start to build more and more,

things, start to learn the design patterns, the architectures, the data modeling that we
have known for years, have experienced with.

But once you're building this stuff, for me as a builder, I've never really been the
strongest actual developer.

I learned enough to be able to build my own stuff, but mostly I'm a product person.

And a lot of people in the world are incredibly smart and capable product thinkers, and
they don't have to

know how all the syntax works.

um And so that's a big focus of what I'm teaching now.

But there's also a huge transition with professional developers.

And that's something else that I see through Builder Methods.

I do some private workshops with teams and stuff.

um the role of the engineer and the product people and the designers on the team, all of
that is shifting.

ah

And there's a lot of anxiety there, there's also like, there are deeper levels to this.

I think there have been a lot of career developers who are a bit slow to adopt and adapt
their skillsets.

But if you start to like lean into this, like we come to the table with a lot of big
advantages that can make, different terms are being thrown around like agentic engineer

and like, you know,

being comfortable like spinning up work trees and being like a product architect and
having the willingness to like let go.

I don't want, like I don't actually hand write any of my code anymore.

I oversee it.

I run these processes.

I do spectrum and development.

I run work trees and stuff, but like it doesn't make sense for me to be writing code
anymore.

uh

read it afterwards?

Do you read it before it gets committed?

some, not all, there's a lot of lines of code that don't review myself anymore.

um

was gonna ask, I was gonna ask how do you feel about these folks that you're kind of walk
through these processes to say, uh sit prompt, understand the databases, understand Git,

understand deployment, don't read a line of code, put this stuff in production.

Do you feel like we are at a spot in the world of uh code, the agent's ability to write
code where they're gonna be safe or are you like, do all that, but only if it's behind,

you know, like.

very careful shutters and if it's gonna hit the public, then you gotta do ABC.

Like how confident are you in the output of purely agent generated code?

I think that there are, there's a lot of different ways to look at this, right?

um

First is like the use case and the scale of what you're trying to do and accomplish here.

I'll be the first to tell you like if you're deploying a product to hundreds or thousands
of customers or end users, you definitely need some real engineers on your team who

understand what's happening and maintaining this, especially if it's a critical
infrastructure.

Like definitely this is not for non-technical people.

But if you are...

building an internal tool just for yourself to use or just for your team of three people
to use internally in your office, nobody else, if it solves your problem, it solves your

problem.

It doesn't matter how clean that code is, frankly.

mean, now the more experience you have, and again, if this, there's always gonna be
security uh vulnerabilities no matter what level you're building at.

um But again, at the end of the day, like,

If it solves your problem, it solves your problem.

Now, I also really believe that, and this is where you can go deeper and deeper as an
agentic engineers that like have coming to the table with the experience that we have as

builders and engineers.

That means that we can make our plans and specs and training and architectural decisions.

um We come to the table with much stronger foundations there, which means the specs that
we have our Claude Code agents or Codex agents, whatever you're using, building off of,

they're following much stronger specs out of the gate, which raises our level of trust of
what it's building, right?

Then you can have like um tests, verifications.

then you can even use AI agents in the code review process, in the deployment, in the CI
process.

Like there are multiple layers of checks and balances that can be built and engineered and
processed without needing to hand read every single line of code.

I mean, that's the big new bottleneck now, right?

For teams, it's like all the code review and all the QA.

that needs to happen, uh it's a hard problem for sure.

But if it's true that we are shipping at the speed that we are shipping at now, we have to
start to engineer solutions to how we trust the code that's being written.

Otherwise, we are our own bottleneck, right?

um

you, m as you think about like, so there's, as people think about AI means a lot more code
being shipped, right?

And I think that anybody who's kind of looked at the relationship between AI and agents
and coding and coders use of AI agents, you can say more code is being shipped across the

ecosystem.

And it's because existing coders are coding more, um bosses are expecting more output,
more people are shipping code than were shipping code before.

And there's a lot of, it's a lot of positives, right?

Like more businesses are being created, businesses are shipping more features.

It's also easy to look at the negatives.

More code is being shipped without being reviewed.

People can very easily point to the, even Amazon was down because of a rogue agent to lead
it, something like that.

So as you kind of look at the most positive and negative impact of these things on the
industry, are you overall, like if you were able to,

either push a button that speeds it up, like even more people coding, even more people
using AEDA code, or slow it down.

Oh, this is all okay, but there's a lot of concerns I have.

Where are you on that button, on that little knob?

I mean, for me, I'm always most concerned with the speed of change that's happening.

I'm not going to question whether things are changing or whether things should change.

I just sort of come to the table with like, accept the reality that like, our whole world
is changing.

clearly changing in the development industry.

The rest of the world, like my non-technical family and friends, like they think I'm crazy
whenever I talk about AI, but like it's coming for them next.

you know, but like, so, look, the world and especially our industry is just gonna go
through some wild times and I'm much more concerned with the speed of it all.

And that's like I grapple with it just like everyone else grapples with it.

Like it's I Feel anxiety that I'm not adopting the newest tools fast enough I also feel
anxiety around like the fact that like I am building much faster But I still have to roll

these things out At the speed of a product for humans.

So like like literally right now, like I have things in my code editor

that I've built just in the last like five or six days that normally I would have rolled
out over like six months.

And um that has like marketing implications and like communication implications.

it's like, like I wanna like announce the newest thing that I just built, but there are
like five things behind it that I didn't even have time to announce, but they just got

built.

So like from a communication standpoint, there's a lot of speed.

challenges.

I'm not sure if I'm answering your question.

um

my big question was if you could either slow down or speed up the pace at which the amount
of code is being shipped, the adoption of all these AI agents, whatever.

And I heard you say it slowed down a little bit.

You didn't say it's bad.

You didn't say you don't want change or whatever, but you did say your biggest concern is
the speed, which to me says let's just slow down the speed a little bit.

Let's make it a little bit easier to adopt.

Well, the good news for me has been often that um we're at the forefront.

Right.

And you mentioned being at the forefront relative to your friends who are different
industries and your family.

But I'm like, we're at the forefront when it comes to technology as well.

Like vast majority of companies have one person somewhere in the company who's poking
around with an agent that we all use two years ago.

Right.

Like it's, you know, some some person, you know, who's using Devon or something like that.

And the vast majority of these companies don't have any way to figure out how to
internalize this.

Any concept of the processes have not figured out what it's good at and what it's bad at.

So

The good news is when you're feeling like you're keeping up, you're keeping up with like
the 1.0001 % of people who are actually really on top of these things.

You're totally right about that.

Even when we feel like we're behind the latest release from Claude Code, we are so far
ahead of 99 % of the world.

um But going back to who are builders and my big thesis right now behind builder methods
is that I do believe that basically every business, they're starting to have them now, but

they will have them more and more internal builders.

Mm-hmm.

And it won't be everyone in the company.

Like I agree, there's a lot of debate right now in our circles around like, oh, is SaaS
gonna be replaced with all these businesses spinning up their own tools?

know, like I'm personally conflicted on this question.

think a lot of, established SaaS will be just fine.

But I do think it's hard to deny the fact that like a lot of businesses can,

make a good argument for spinning up their own internal version of a SaaS that they used
to pay a lot of money for.

uh There will be at least some members within organizations who are like internal
builders.

And maybe they have some development experience, maybe they don't, but they are getting
their, the speed at which they are able to start to adopt things like Claude Code, like

non-technical people building with it internally is going much faster now.

uh

I just think that that's a trend that's gonna continue.

So businesses are gonna develop their own internal builder people.

They're gonna look to hire more internal builders.

Founders and smaller shops are gonna become more builder oriented themselves.

uh And then those who are just not uh interested in learning how to build their own stuff,
they're gonna find someone or partner with someone or hire someone who can.

Yeah, and one of the things you said earlier is you said, well, this is very different for
internal tools versus public facing tools.

And the thing is, SaaS has often been, we are going to build a tool facing the public, you
the users are going to use it internally.

so like SaaS is basically offering internal tools, but we're building it for all y'all to
use.

And so the idea is that each time somebody says, you know what, I don't want your SaaS
offering, I'm going to build an internal version of it.

That's one license lost for that SaaS creator.

But I think the helpful thing is, uh

It takes time, energy, um knowledge, training to be able to build and maintain those
internal tools.

The number of pieces of software that are being built and shipped that are great for a
demo, that are not good enough for long-term usage, and that will not be supported in

terms of the cost of their technical maintenance, because we all know tokens are going to
get more expensive.

in terms of the cost of whoever was working on it to continue to be working on it.

Like they built it in their nights and weekends.

They're probably not always gonna have that energy forever.

Like I both believe that there's gonna be a lot more internal tools and a lot more
capacity and excitement for people building their own tools.

And I think that that move right now is bolstered by cheap tokens, people's excitement,
know, not having been burned by the security gaps that happen when some junior.

builds this whole tool for you, then sucks up all of the private data and then oops, it's
actually accidentally exposed to the internet and now you set up a company policy where

you can't do that anymore.

Like I think there's a lot of breaks that are coming soon where it's gonna keep happening,
but I don't know as someone who helps people build SaaS, I don't know if I'm super worried

for SaaS.

Yeah, again, it's like I'm very conflicted because I think there's so many different
flavors of it.

I think they're absolute like, to me, like the more critical and the more surface area, a
tech a piece of software touches, the less likely it should be or will be relied upon as

like an internal tool.

But there there are

I just think that the idea of internal tools is going to spread so far beyond what a lot
of people are willing to imagine right now.

And a lot of them are just personal tools.

professional people within larger organizations are just gonna spin up their own internal
tools that they just use to do their job.

Even if their other coworkers in their department never touch their personal tool or their
personal skill or agent or whatever they're using, uh a lot of that will happen.

But there's also just to me the idea of like SaaS, like yeah, I still pay for some SaaS,
but I also, I'm always frustrated with SaaS.

And I think most people are frustrated with most of their tools that they ever use in some
way.

Even the SaaS that you love and have paid for for years, everyone has to admit that
there's like 10, 20%, maybe more that are like paper cuts that like, I know that.

I know this app that I use, this email marketing tool that maybe that's a bad example, but
like this CRM tool, I know it sort of solves my problem, but it's got all these other

features that I never touch.

And I wish I could just do this or that thing because my use case demands it, but I know
that they're not going to ship it to their, cause their other thousand customers don't

need it.

So then it's like, how many little paper cuts are we willing to put up with before it's
like, well,

I could just build my own little CRM that works absolutely perfectly for the way that I
need it to work for me, you know?

Well, I'm glad that you picked CRM because I actually have been, we have been thinking and
talking about building our own internal CRM and have poked at it three times over the

history of Tighten And I've always just said, it's not worth the time and energy.

Let's just go back to using what we're using.

And six months ago, my director of engineering, Keith, he's like, Matt, you have
complained about this CRM every single time we've been in a marketing call.

Why don't you just go build it?

So I built it in part because it's helpful to build it in part.

because I need to stay kind of fresh.

And so if I'm talking about AI, need to build AI.

And it is exactly the trap that I see our clients have all the time, which is it seems
simple, right?

I'm like, all it is is a client record for each person.

They have these certain properties.

I need to be able to list them, view, you know, edit, create, whatever, a couple
integrations, no big deal.

And I ship that in less than a week, right?

And I'm like, yeah, this is exactly the promise of AI.

I'm still building the thing, Brian.

I'm still six months later, weekly,

putting hours and hours and time because I'm like, yeah, but I need that feature.

that feature is not that easy.

I need that feature.

That feature is not that it needs to integrate with this tool.

that's not that easy, right?

And that's the thing is I agree with you.

also, I think that there's a people are even more likely to fall in a lot of the traps
that people have been when building SAS when they've had advisors, people who know how to

build before, people who've been in the bootstrap community, people who run agencies,
whatever, telling them,

Okay, I understand that, but you're not thinking about all this.

They're going to build or make plans to build without all of that advice, without all that
experience, without all that, hold on, you're not thinking about this.

And so I do think we're going to get a lot of like the number of one third finished
internal vibe coded apps that are going to.

Yeah, yeah, right.

Everybody does who's doing this.

And I think that this internal thing, there's like a I'm not saying it's not going to
happen.

There's like a maybe a reckoning or there's an adjustment or something at some point.

the excitement's gonna come down a little bit, but I also think at some point the normies
are gonna get in.

There's still a lot, we're still in the middle of lot of transition here, right?

Oh, yeah, for sure.

This transition is just going to continue.

But I also want to push back on the idea because I think the general consensus is like
vibe coded tools, vibe code in a weekend takes just a day to ship this or that.

Yeah, technically you could build something in a day, but like there are multiple tools
that I'm using every day that I built that it did and it does take me multiple weeks.

still to design and build the right solution.

And then I'm still iterating and maintaining it.

And that is a lot of work.

And it takes a lot of experience and background to be able to maintain it.

But it is still to me more efficient uh than buying another tool, not just the cost of it,
but to me, it's more about the cost of the features that they're not gonna ship for my use

case or the interface that just doesn't work with the way that my brain works.

You know, um, like there's, there's a tool that I use every day and how I develop content
and builder methods that I designed and built recently.

And I'll just be like sitting on the couch using it on my mobile device and something will
bother me about my own design decisions or how, how it came out.

I'm like, ah, this button shouldn't work that way.

And then there's while I'm on the couch on mobile, I'll fire off a task to claude code to
fix and deploy that thing in my own tool.

And it just, and like.

These are, but if you think about the way that businesses have always run, back when I was
teaching productized services, literally that whole course was about how to build

processes and hire a team and deploy them with your team.

we were building processes with Google Docs, step by step, if this, then that, we're
programming a system here.

It's just processes that people run now.

people have operationalized their business and systemized their business for many, many
years.

um And people think this way.

Like they have that systems mindset, that product mindset.

And now that you can describe processes to claude code instead of a Google Doc and have it
actually turn into a tool that you or your team can use.

mean, that's pretty incredible.

And frankly, like the thing about like maintaining this stuff over time, like, yeah, like
absolutely that's a real

need.

It's a real problem.

It's a real challenge.

But it's a challenge that can be managed and maintained by an internal builder who knows
how to operate with Claude Code.

And then if you think about like, okay, 4.7, Opus 4.7 just dropped.

It's a little bit smarter than the last one.

Where are we going to be six months from now?

12 months from now?

The models are going to be even, even smarter.

So like everything is just going to keep getting better and better.

uh It's not magic and it does

require effort, especially from a product.

I would say the biggest skill to me is product management at this point.

designers and product managers, I think are probably in the best position to sort of
thrive in this transition because you just don't need to have the expertise of handwriting

code and making sure that this type checks out or this syntax works.

um But you do need to know how to architect the right interface and the right user
experience, you know, um especially for internal tools like that.

That to me is what's most important.

And that's where like, if you have experience as an engineer or a UX UI designer, like
leaning into this stuff and being really strong at developing strong PRDs and specs.

and uh agentic systems, like that's what it means to be a pro builder in my opinion.

Yeah.

And as we've said before, a lot of that is specific to context, right?

Like you're talking about building internal tools, you're talking about that, you know,
like, because you just said, like, it's less valuable to understand how the code works in

context, right?

Like there are contexts in which each of these different groups are more or less needed.

And I have referenced that, I think in maybe the last three podcasts that Justin Jackson
pointing to the...

the Spider-Man meme where there's three people all trying to take each other's jobs,
putting each other in.

It's the designer, it's the product manager, and the technologist, right?

And the technologist could sit here and say, I don't need a designer anymore, because I've
got Claude, right?

And they can all say, we don't need the product manager anymore, because we've got Claude
to do that for us.

And I think that's the interesting part for me is that everybody looks at Claude or
whatever else they're using as the ability to replace the need to have the other people.

But so far, everybody I know who's really spent time with it ends up saying, but you still
need to know, you still need to understand how programming works.

You still need to understand, have the vision for the design.

You still have to the training, whatever.

um I'm curious though, because you do have a development perspective um and you're saying
the development knowledge is less necessary.

uh Are you finding that you can train people who have no development background?

to be able to build sustainable, secure, scalable apps, or is it more, we can train people
to be able to prompt well enough that as long as you don't have those constraints of

massive security concerns or scalability concerns, we can just put bubbles around the apps
to make sure that they're firewalled to the point they're not up to the public.

If they don't understand it, what is the quality of what they're producing?

And I'm not trying to lead you in either direction.

I'm really trying to figure out your kind of position here.

I think, again, I hate this answer, like it always depends on the context, but but if I
just think about what I'm doing all day today.

uh All my time, the hours and weeks that I put into the tools that I'm building is spent
in plan mode.

Like um I'm in plan mode all the time.

I'm not doing the building, I'm doing the planning.

um

you.

I'm talking about your students.

Whether you know or not, you have 20 years of development experience, right?

You're planning

when I'm planning, I'll have like one work tree open where I'm planning.

it's absolutely true that like my experience as a developer and designer is absolutely
helpful in the work that I build for sure.

um But the job today of a builder is to be a planner.

Like we're spending our time.

It's not just prompts.

It's like plans, specs.

and going through a deep uh back and forth with Claude or your human team to understand
the requirements and shape up the needs.

Like this is the human skill.

This will never go away in my opinion, right?

uh Is like uh shaping and planning and customer research and...

uh

and understanding what is the core problem that we're solving and what are we not solving?

What don't we have to solve?

And then like that's really question number one.

And then question number two is like, okay, what, there are 50 ways to build this
solution.

What's the best one for us, right?

um And the process and the ability for us to interact with a Claude agent or a Codex agent
to go through the many questions that lead us to the right

plan or the right spec.

Like that's what I spend all my days on, right?

Like it's, em and so, and I think that that is a skill that can be learned.

uh Yes, you and me are gonna get to that answer a lot quicker than someone who doesn't
have the engineering experience.

And I can read a plan from Claude and understand a lot of the technical bullet points a
lot faster than someone who doesn't, but someone who doesn't can just ask follow-up

questions.

And then they just do that again and again.

now they're just quickly advancing their own knowledge set and their own experience.

And if you think about like, I learned Ruby on Rails maybe eight, nine years ago.

um It took me over a year of courses and practice projects to start to understand just the
basic concepts.

um And if that were happening today, I could advance through that

that year of full-time learning, I can condense that now into under a month.

Yeah, there's always gonna be more experience that can be gained over years of building,
but like the fundamental stuff can be learned.

I just always come back to this idea that like it used to be we spend maybe 20, 30 %
planning and then 80 % building and coding, and now it's flipped.

Like I'm spending 80 % of my time.

90 % of my time plus, like just planning.

And that comes in different forms of like chatting with Claude, writing plans in Claude
code, reviewing specs, um and then just pressing go and letting that build.

And while that's building, I go plan the next thing.

And that's how I have multiple things running.

um So I do think that that like cadence, that workflow can be learned.

um

Where am I going with that?

Yeah, I don't know.

I'll leave it there for now, I guess.

Yeah.

So we're getting close to time and I wanted to make sure we had a chance to cover all the
things that were kind of on both of our agendas.

I think I've gotten a sense of kind of where you're coming from.

I do want to ask, how has your view of AI changed in the last six months?

So you talked about you started Builder Methods in the middle of 2025.

So you were months into being a AI educator six months ago, but

I don't know about you, but a lot of people I know felt like Christmas 2025, that period
was really a big shift.

So as someone who is a little bit more kind of like on the leading edge of everything, you
were already trying to teach people like, has your perspective on AI, impact on society,

your relationship with it, anything like that, has it changed a lot over the last six
months?

Oh yeah, it's always changing.

You're right, I think that the December 2025 is that moment that everyone is gonna
remember and has been talking about.

I noticed it for sure.

Like what was so interesting to me as an observer of everything was that seemed to me to
be the turning point where for most of 2025 and definitely 2024 and earlier, there was a

ton of skepticism out there.

with AI in general, especially AI in the software development industry, it's not good
enough, it does slop, it hallucinates, all this stuff, which is all true.

And then I think it was like the drop of Opus 4.

I forgot which one it was, 4.5 at that time.

um And people had time over the Christmas break, holiday break to uh play around with
stuff.

And that's when I just noticed that like all these people who are like famously skeptical
started to come around and say like, actually it's pretty good.

And then I just started to see like a general shift where like it used to be 50-50 or less
than 50-50 of like, I'm for AI or I'm against AI or I don't use it or I choose to use it.

Now it's like, if you're a professional in this industry, you are using it.

Maybe you're grumbling about it.

Maybe you're slower to adopt the most, like,

To me, it's almost like borderline malpractice to not use it in some way, or at least be
aware of how it's being used on teams um at the professional level.

um So that shift has just been interesting to me.

In terms of my view, um I'm always observing my own use of AI and seeing how that's
changing.

And that is changing a lot too.

So...

At that time, like December, 2025, I was already heavily using AI in my work.

I was probably getting up to the point where I was not hand coding anymore.

would say like early 2025, I was still like 50-50.

would like 50 % of my code base would be written by me, maybe with some tab completion.

And then the other 50 % would be written by agents in cursor or cloud code.

And then by the end of 2025, I was closer to like 97%, like not hand coding and just
focusing my effort on specing and a lot of effort on specs and then having it build.

And that's still the case today here in the beginning of getting into mid 2026.

The shift for me now is multitasking.

Like people have been talking about work trees and

and managing and orchestrating multiple agents going back to last year.

like I personally, I knew how that stuff worked, but I personally didn't really adopt that
workflow because it's just too much to manage mentally.

Like I can't think about, I can't build four different features at the same time.

Now, I still don't go crazy with it, but I do have multiple threads going or multiple
agents working on stuff at the same time.

I think.

Most of that is because of a few shifts that I'm seeing lately in my own work.

Number one, I trust the models more like Opus 4.7.

use a lot.

I trust my ability to plan and spec and give them the right training to do stuff.

And I just give them much larger tasks to work on.

most of the projects, most of the things that they're working on, they'll

it'll be spinning for 30, 45 minutes while I'm planning the next thing.

So that's why the multitasking is coming more into play for me now.

And then the other exciting thing that the whole industry and myself included are
interested in and using now are agents.

So I do have like multiple agents that run autonomous tasks on a schedule.

even have a chance to talk about these in this podcast, but can you give like if
somebody's never heard of OpenClaw, can you give me like the one minute rundown of what

they are and how they're working for you?

Yeah, and OpenClaw is one that's huge, but I'm also shifting a lot of my agent stuff to
just claude-based stuff.

So like claude co-work and claude code.

um But yeah, OpenClaw, I have a second Mac mini sitting on my desk here, which only runs
agents.

It has no computer screen, no monitor connected to it.

uh So I have agents that run autonomously, um meaning

they follow skills, which are like processes, and I give them tasks to work on.

A lot of people use agents in different ways.

A lot of them just use them as like direct, like, hey, let me chat with you, ask you to do
a thing and come back to me.

Like that's sort of interesting and helpful.

To me, it's much more interesting to say like, I want this task done every morning at 6
a.m.

Just run it on a schedule.

uh So I have agents that...

that monitor content on Twitter for me or uh pitch ideas for potential content that I
might develop and then even helping me draft content.

uh I've got agents that uh check some PR review stuff and give me reports, uh some
reporting stuff on metrics.

uh There's like 10 other tasks that I plan to give to agents once I have time to

to take the time to engineer the right processes for them to follow.

Again, there's a lot of magical stuff out there that it's pretty cool once you stand it up
and deploy it and get it up and running.

But I still think it takes a lot of time and effort to craft the right process, the right
architecture, the right strategy.

But it's just an exciting time to be able to tinker and build with this stuff.

uh

I love it.

And I told you this beforehand, but it's been fun kind of watching you teach on the
internet in a way that people are responding to very much as like, I mean, the pragmatic

AI is the name of the pragmatic.

It's that you are teaching how to build things, which means you're not just teaching
theory.

You're actually trying to teach things that have a practical benefit.

And from an AI perspective, I'm a big fan of that.

From a coding perspective, I mean, I would...

much rather code with AI to do something that builds something real for people than code
without AI and have it not be useful, right?

Like the goal is not to write characters on the screen.

The goal is to actually do things for people, allow them to do things they couldn't do
beforehand.

And so it's been fun watching, you know, your builder methods really be focused on
building real things for real people based on real needs.

Yeah, and I love that you started this podcast when I saw it come up a few weeks ago.

I just think seeing more and more of us in this industry talk more publicly about how we
are adopting and changing our workflows with AI.

It's important.

It used to be like, this is interesting.

But it's a real...

important challenge that we all have to like wrap our heads around.

So I think the more that we could just talk about it and share notes publicly for others
in our industry to uh kind of grapple with all this stuff is helpful.

So it's the thing now, you know.

Yeah, it is the thing.

All right, well, you know that one of the things that I do to wrap up at the end is I like
to share something that somebody from the community has shared in the ways that they're

using AI.

So Joey Kudish said, Chat GPT helped me find the house I've been staying at in Thailand
for the last seven months, changed the course of 2025 and 2026 significantly for me and my

partner.

So Brian, I was curious for you, have you used AI to do vacation planning, family trips,
stuff with your kids?

Okay, any pro tips?

He's a member in the community.

So, yeah, literally last week we took a spring break vacation.

We were down at a beach stay down in Florida.

Three weeks before that, both me and my wife were on chat GPT saying like, all right,
we've got a couple of days over spring break.

We know we want to be on a beach.

We were flying from Connecticut.

Give us some ideas.

Yeah.

And I've done that for multiple vacations now where it's just like, high level, we wanna
be on a beach, we wanna do some hiking, we wanna do something, but we don't know where,

we're open to all ideas on the table.

Give us a bunch of ideas.

Okay, these two seem interesting, those three not so much, let's zero in on those.

Okay, so now where's the coolest place to stay in those areas?

It is not up to the point where it's like, okay, find us the hotel.

and the flight to book.

But it gives me the zero in.

like, okay, I know what I want to be in this area.

And it worked.

Yeah.

Yeah, I've been telling people a lot in the podcast, especially in these end segments, and
realizing that I'm most comfortable with AI and casual data uses if I think of it as a

much better Google, as a much better search, it's a much better way of discovery.

Like last night we were booking just a quick overnight thing with the kids for the summer.

They've got a cousin coming to town and we want to take her to this water park.

And I was trying to figure out whether it was better to buy a day pass or to buy a single
night.

ah Because if you do single night you get a day past the day you arrive and the day you
leave and I was like it should be clear But I'm having a lot of trouble and so a you know,

like these things are LLM So they're really good at language but B they have access to way
more documents than the two I have in front of me So I just asked the question and I'm

like, please explain and show me sources

Which of these is better and they're like, well, if you're thinking about this, then I was
like, you know what?

I hate to this, but I didn't think of for those different reasons, but I was like, all
right, so let's answer all those.

So now am I right that this one is actually six dollars cheaper for two X the amount of
waterpark time?

And they're like, yeah, that's absolutely it.

Here's the sources.

And I was like, I would have been Googling, right?

I would have.

It's not as if I'm replacing my human logic or my human tooling.

It's just it's just a tool, but it's a tool that is better served for this sort of
intelligence search and language parsing and.

consuming.

So it was pretty fun.

I felt more confident in my answer given that circumstance.

Totally, um I do that kind of stuff all the time.

I don't know about you, the way that I have it set up in my life now is like, chat GPT is
my personal life uh stuff and Claude is my work life.

um Yeah, and then in chat GPT, I've got like a folder for like all of my weird health
issues that I need to ask it about or, uh you know, like book recommendations.

Like, yeah.

esoteric interests I have.

Yep.

Yeah, that's called being in our 40s.

Jeez.

I also don't know about you, but I just heavily use it as, people call it different
things, like a thought partner or a strategic coach.

This is more on the work side for me.

And now this happens more in Claude, but like, you know, I talked about how I spent a lot
of my time like shaping projects and shaping plans for...

products and stuff, like there's multiple steps before that where it's just an idea and I
go through lots of back and forth just with Claude.

uh And a lot of it is not even product related, it's just like strategic direction
related.

um I really do attribute a lot of the recent success in builder methods or the clarity
that I've had to a lot of these sessions that I have with like,

cool.

tell me what to do, but it just hears me out and pushes back.

And um it has my whole history of all these decisions and conversations that I've had over
the last couple of years.

like, it's all built in there.

So when I'm thinking strategically about where I wanna go next to my business, I'm gonna
spend a lot of time like voice noting and getting feedback.

And that's been incredibly, incredibly helpful for me.

That's helpful.

I have a leadership team that unfortunately like it or not, they have to be that for me.

So I haven't kind of leaned in a chat for that.

But if I didn't, I could imagine that.

But one thing I have found is that there's parts that are specifically my role at Tighten
where I'm not asking anybody else to handle it.

And I'm not always the right person from a personality perspective or from an ADHD
perspective.

Like one thing I should do is really stay on top of certain types of communications and
movements in the industry.

And I'm like, I just can't watch this hour and a half long video.

It's been on my, it's been an open in a tab for ages and I found myself more and more
often.

I'm like, if I'm not going to be able to do this rather than closing the tab, copy the
transcript, paste it into the chat and I'll say, Hey, given everything, you know, about me

and my business and our previous conversations about this, can you tell me if there are
any key moments I should pay attention to any takeaways I should have, or just buckle up

and watch the freaking video at one and a half X speed and you kind of give me something
to work with.

It's not making decisions for me.

It's not thinking for me, but man, it really helps my ADHD for it to say.

this literally doesn't relate to you or here's the one piece or here's the one way to
think about it.

And unfortunately, my poor leadership team now have started getting messages with me or
I'm like, all right, here's what I'm thinking.

I talk with Chat about this and they're like, and I'm like, sorry, you know, like it was
either we completely lose this in this video's influence on the future of this company or

this was the way it happened.

And I'll take it through, you know, filtered through an AI versus not at all.

Yeah, I mean, that's a really good open question, I would say, uh is like the multiplayer
experience with these AI tools, right?

I've seen it.

I've seen the need pop up a few different times, like in my personal life, like Amy, my
wife, like we were both, we were planning this vacation and then we were also dealing with

like a health thing with one of our kids.

uh

And like we both wanted to consult ChatGPT on some of these questions.

And I found myself like doing it and then sharing the link to her or copying and pasting
what ChatGPT said to her.

And then she would paste it back to me.

Like, how do we share access?

I know they have sort of like a sharing access, but it doesn't really work so well.

So it would be nice to have like a family account that like, that we can all see and chat
with together.

uh There are ways to rig that up.

But then I was, I also heard

Justin Jackson talking about this, he recently was sort of vibe coding a new internal
product or a new potential product from Transistor.

But instead of just doing it himself directly in Claude code, he was doing it through
Slack, like using the Slack integration with Claude code.

So, and prompting Claude code through Slack, it's really just Justin and Claude doing it.

but everyone else on his team can like observe and see him like interacting with it, you
know?

uh So I think that's like a direction that I know that a lot of teams need to figure this
out and families too.

So it's like, uh how do we share while having the privacy aspect and all.

Yeah.

Well, I really appreciate you hanging out today.

This has been so much fun talking.

I actually really enjoyed the end section more than I expected.

Like we should just hang out some time.

But if people are curious to learn more about you and what you're doing, what's the best
way for them to keep up with you?

Yeah, so you know, I'm working on buildermethods.com.

um I'm on YouTube.

I mostly pay attention to Twitter, X.

I'm also on Blue Sky, but I would say, yeah, X at CasJam is where I'm at.

yeah.

By the way, I also podcast with Jordan and Justin too.

So we do that every week.

I like that as well.

Thank you for coming to Hangout today.

Thank you for your time.

Thank you for dealing with the fact that I was in the wrong um Riverside room when you
showed up.

We got there eventually.

All right.

And for the rest of you, we will see you all next time.