Build vs. Buy

CJ: Welcome back to Build and Learn.

My name is cj.

Colin: And I'm Colin.

And today we are talking about whether
you should build versus buy software.

It's that classic build versus buy
decision that, you may or may not

have encountered in your day to day.

But we're gonna dig, dig
into it a little bit today.

What kinds of things have you been up
to since we last chatted last week?

CJ: We're kind of winding
down the summer here.

Our kids are getting ready to go to
school, so we're, Yeah, we're kind of like

starting to enter into hibernation mode.

, I guess, like cleaning things up.

Colin: coming.

CJ: Yeah, winter is coming
eventually sometime.

We haven't experienced a fall in New
England yet, and so we see some trees

starting to turn and we're getting nervous
about how many leaves we're gonna have

to pick up and like all of this stuff.

So yeah, we're getting, we're
getting ready for that transition.

I think the kids are excited
to go back to school.

Third and fourth grade, it's, good times.

Colin: Nice.

CJ: I know at this time of year also
that like right at the end of summer,

beginning of fall, a very special
thing happens in Northern Nevada.

And so , you know, if you're going
to unr, students will be off campus.

They're just gone Teachers too, right?

If you're in, if you're in and around
Reno, you start to see all of these

like really wild looking vehicles
passing through and, you know, there's

a lot of dust on the road, , so
there's a special thing coming up.

What, what have, what have you got going?

Colin: Yeah, I feel like we're lit.

Lit.

I mean, we are in different
parts of the country, but.

You're talking about leaves turning
and I'm thinking about how hot

it's gonna be, out in the desert.

Yeah, so Burning Man's coming up.

I know it's a pretty popular
thing in, in tech circles.

There's a lot of like preconceived
notions of what Burning Man is as well.

And, you know, it's, it's
definitely a lot of fun.

This is gonna be my eighth year since.

I guess my first year was in 2008, so
I've been going for a while kind of

off and on and have run theme camps
and really big groups out there.

And I'm kind of now like more of
one of the, the veteran curmudgeony

burners that, you know, just wants to
go out and build my shade structure

and, do our own little things.

So no, like official like duties that
I have to do while I'm out there,

other than like build my shade,
build my structure, and make sure

I have enough food and water, and
then just kind of enjoy the whole.

CJ: Nice.

Do you bring out water to bathe with
or like shower with or are you like

one of the hardcore people that are
just, I'm gonna be dusty and I'll get

super, super dusty when I get home I'll.

Colin: Yeah, I mean, what's
interesting about it is it's,

it's like an alkaline dust.

It's, it's not like if you went
camping in the forest where like a

few days you're gonna feel like dirty.

It's really interesting cause it's like,
think about like Mad Max or, you know,

like it's just like very fine baby powder.

and it's very easy, like you actually
feel kind of clean in a weird way.

Like you might be covered in dust.

So some people try to like do all
sorts of cleaning regimens out there.

It baby wipes are your friend, basically.

Or like the really large
format ones you can get.

Yeah, some people try, they do
like solar showers and stuff.

The issue is, Bringing out enough water
cuz you're already wanting to bring

enough water to cook and, you know drink.

And so it's part, and then
you gotta deal with the water.

Like you need to try to like, deal
with your waste water after that.

So you're not supposed to pour
things onto the ply like that.

We could go on and on for a whole episode
on, on this, like because a lot of people

just think it's like a, you know, party
in the desert, which it very much is, but.

A lot of people who have never been
before don't realize how harsh of

an environment it is out there.

And yes, you can buy ice and there's
people, your neighbors are gonna

help you if you forget something.

But it is one of the more inhospitable
places on the planet to go to

CJ: You've gone eight years.

Are you doing a theme this year or

Colin: I am with a, yeah, I am with
a camp, but it's like, again, a camp

of people who have done it for so
many years that we don't really want

to, like, some camps have dues and
you gotta sign up to do group cooking

and like events and all that stuff.

And so our camp, we actually
record like on behalf of the,

the Burning Man Organization.

Things at Burning Man in vr.

So 360 degree video.

We're gonna be out there
with I think it's like.

Oculus Goes which are like an older
version of the Oculus that's like really

lightweight, indestructible version.

Doesn't have to be tethered to a computer.

And it is, you know, I thought it
was a little bit corny at first.

It's like you can't, like,
why not just enjoy it?

Why try to capture this?

But the people who started it
are literal, like librarians and

documentarians who are trying to create
an archive of what's going on out there.

And so they get invited to go
out in the middle of something.

You as even an attendee aren't
allowed to be in the center of

and get to capture that in, in 3d.

And then teaming up with other groups.

There's a group called BlackRock B
R cvr, that does more of the like

3D metaverse avatar side of things.

So you get to actually like, If
you're not on ply, you can on

your Oculus at home and, and be part
of the, of an experience out there.

And it's kind of interesting cuz it's like
obviously never gonna replace what it,

I mean it's hot and dusty and all that
stuff doesn't come through obviously.

But like half of it is like getting
through the day cuz it's hot and you

get to see all these amazing things and
you're running into people and then at

night you get to go out and it's just.

Every l e d that you've ever seen on the
planet, all in one place and fire and

just, it's a, it's a really good time.

So

CJ: Something that I've heard is that
you can't actually buy anything there.

It's all like a barter system.

So in today's episode of Build
versus Buy, literally you have to

build everything . You can't buy
anything or you have to train, right.

Colin: Yeah, we can jump into the theme.

But yeah, that one also gets a
little bit of misinterpreted

because they do sell ice.

Just because it will be very
hard to be out there, like, I'm

gonna be there for nine days.

You can be really good at packing
a cooler and nine days you just,

it's gonna be melted no matter what.

So you figure out things that
don't require refrigeration

and ice and things like that.

But, you know, having a.

Beer on ice is also a luxury to
have, so they do sell ice, but it's

more of a like a gifting economy
and that there is no real economy.

It's just that some people will
bring gifts, quote unquote, and that

gift might even just be helping you
build your shade or build your camp.

Right?

It doesn't have to be a thing,
and it's not an expectation that

you're giving something back, right?

In some cases, this.

Open source if we want to go there.

Like there is a lot of reasons why I
think developers and, and community

minded people are attracted to it is
that, Yes, you gotta buy a ticket.

Yes.

Technically going to Bernie
man in general is expensive.

Like it is a privilege to go
because you gotta have the

time to go, the money to go.

You know, unfortunately, you know,
it, it ends up skewing towards

the demographic that is allowed,
like, is able to make that work.

Once you have paid to go and you
get there, you're not spending

money, someone might just make a
bunch of stickers and pass them out.

It might just be an act of
kindness that they're doing.

And then some people go all out and,
you know, cast little figurines out of

silver and you know, randomly you might,
you know, just because you talked to

somebody that did that, they might give
you on and it, you know, you're not doing

anything out there with expectation and
you're not trying to, you know, collect

all these little gifts or anything.

It's just an interesting thing
of like, you know I'm not gonna

be doing this with an expectation
of return or something like that.

CJ: I also am really intrigued
by the way that it's set up

like the, the actual layout of.

The city because it is a city, and I
think someone recently shared a, an

image of like Mesa, Arizona, which
is also sort of laid out in a circle

where everyone is, it's easier to sort
of like cross the city to any point,

rather than having it laid out in
like a perfect like rectangular grid.

Colin: Yeah, an architect designed
that and or many architects probably.

But it was, it's interesting cuz the,
yeah, the way that your addresses are

actually based on the hours of a clock and
then, Rings inside of that circle are the

different streets from A to H, and so each
one has a different name, but you can just

say like three 30 and a, and if you're
at 12, midnight, right, midnight, then

you can figure out where three is, and
it's pretty interesting way of doing it.

There've been some like competitions
and, and to like redesign the city

and you get all sorts of interesting
things, but then you end up realizing

it's like, okay, now to get from
one side to the other, it takes you

twice as long or you don't know where
you're at in relation to other things.

Like it, it is a really interesting
thing and like clocks exist around

the world, so it's pretty easy for,
you know, a global audience to pick

it up and know what, what that means.

But yeah, so.

CJ: it's, it's like a, it's an annual.

Beta test of like how you
should lay out a city.

Colin: Yeah, I think it would
be fun to change it every year.

But yeah, I think everyone
would get super lost.

CJ: Yeah.

Cool.

Colin, at Rails Comp this year
did a talk about build versus buy,

and a lot of it was around sort
of stuff at your current role.

But yeah, just kind of curious like
Where we should start and maybe we can

like set the stage and talk about what
the difference is or maybe kind of

like who might be making this decision.

Colin: Yeah, I mean my, the talk
that I did was specifically like

build versus buy on rails, which
we can talk about in a little bit.

That one was kind of funny cuz I was
like, is this resy enough for rails comp?

But I think, you know, I, I did
pretty good justice there because

it is a decision that everyone
will eventually have to make.

And it might not mean that you're physic.

Taking your wallet out and buying
something, it might mean using an open

source library or a gem or, you know,
whatever modules are in your language.

But to kind of set that stage, it's
any time that you can think about

building something from scratch or.

Buying something, using
something off the shelf.

Or I would say the third pillar
would be inter implementing

something from off the shelf, right?

So you might use something off the
shelf or buy something, but you

still have to build to it or, you
know, implement it into your system.

So build versus buy kind of simplifies it
where it's like something like Zapier is

something you're buying and you don't have
to necessarily write any code for that.

But you know, is it enough?

I would say like in the topic
of integration, some companies

just say we have Zapier, right?

And in some cases that means that they did
have to do some work to build to Zapier.

But they did that once.

And now Zapier's gonna build
all the integrations points.

And for some companies, you know,
like an indie company might love to

do that in indie, customers might
love that, but an enterprise company,

You know, saying like, Here, go use
Zapier probably isn't gonna work.

And so that's where that
starts to evolve a little bit.

But yeah.

Has this kind of come up for you in
your work or like the decision in

your role, or how does that come for

CJ: I mean over, over the years I've
definitely run into this a bunch

of times where, I mean, probably the
earliest instance I can remember was.

Trying, just trying to save
money on little side project

ideas that I was building myself.

Like I was spending a ton of money on
Heroku and so I was like, Hey, I bet I

could use a digital ocean droplet for way.

Less money if I can just build some of
this stuff myself with open source tools

like Engine X and whatever other stuff.

And it ended up being like a giant
pain and it was totally worth

just spending the money on Heroku
for hosting instead of trying to

build all the like, infra myself.

Colin: Yeah, so you had
a trade off there then.

CJ: Absolutely.

Yeah.

There's always gonna be a trade off and.

It's really hard.

I think, I don't know, it's, it's really
hard for me personally to not build

something , and so right now I am.

Thinking through my content
process, for instance, right?

Like if I'm, once I make a video,
I want to transcribe the video, I

want to use that transcription with
open AI to generate tweets and video

descriptions and titles, and then
I want that to pipe into TikTok and

all these other social media things.

And I wanted to track the
analytics for all of that.

And so my immediate first.

Reaction as an engineer is
like, Okay, I can go build this.

But in reality, what I'm now, like
literally today, setting up is air table

so that I can just use a bunch of tools
that are already built in to air table.

It's like this, no code
off the shelf thing.

Maybe I pay 10 bucks a month, but
now I don't have to maintain my own

hosted Heroku Frankenstein of like,
Okay, here's my video workflow.

So,

Colin: Right?

Yeah.

I think what you touched on there a
little bit is what some people have

called like not invented hair syndrome,
and as engineers, we really do enjoy

building things and it's very easy.

To trivialize how easy
something will be, right?

You're like, Oh, I can do this
in a weekend and it's gonna be

worth saving all this stuff.

But you, you don't have the
knowledge of everyone who's come

before you who has tried to do that.

And it almost always, You know, I,
this is even in building features.

Like I try not to ever say that will
be easy, like ever because there are

edge cases and gotchas that, you know,
even sending an email, it's like,

Oh, I can just do SMTP by myself.

But like Send Grid exists for a reason.

CJ: Mm-hmm.

Colin: There are issues with
deliverability and there are issues

with like even just making sure
an email address is a real email

address before the email goes out.

You end up paying for
and it's a trade off.

But if you try to do all of sun grid
yourself, that's when I start to

argue like, Should you be doing that?

CJ: There's a funny story that I
heard when I was working at this

robotics company a long time ago, and
it was a, a story about a monorail.

And so there's like some airport and
the problem they were trying to fix

was like, Oh, we don't have enough
parking and so we're gonna build a

parking structure like really far away.

And then you know, oh gosh, how
are we gonna get the people from the

parking structure to the airport?

And so they.

Instead of just being like, Oh, let's
make like a road and use buses, and

we'll just like buy a bunch of buses.

They're like, Oh, immediately
we're gonna overengineer this

and build our own monorail.

That's gonna be like super epic, and
it's gonna have all these bells and

whistles and there it'll be unmanned
and automated and all this stuff.

So, you know, like I don't, it,
it's, it's a really good story when

you're thinking to yourself, Should
I build this as an engineer and be

like, Okay, is this a monorail like

Colin: Yeah.

Am I building a monorail right now?

CJ: Right.

Yeah.

Colin: Especially relevant
if you're using rails.

CJ: Yeah.

. I didn't think about that.

Colin: Yeah, I think I saw someone in
the community was tweeting about how

we should have a hackathon on a train,
and I swear I've seen this before, but

they were like, Let's do rails on rails.

And I was like, I swear this is a thing.

Like I think there was a caboose comp
for something like that one year that

was like a conference after Rails
Comp, which was like super hilarious.

But like, I would do a rails
on rails like sign me up.

CJ: I think the maybe combining rails
on ails, like the beer conference,

like rails on ails, on rails, like

Colin: Yeah, we stopped at
micro bruise along the way.

CJ: Yeah, exactly.

Colin: Yeah, I mean, It has to
be on a monorail and majestic.

Majestic monorail, right?

That's gonna be the new
Monorepo is a, is a monorail.

But I, I see this a lot at companies,
especially for engineers who don't

talk to customers or aren't in touch
with the business side of things.

It's very easy.

You know, build stuff.

And the thing that, that I've really
come to, and you see this on like the

more indie hackers side of things too,
is like you as a business, you have

an infinite or so, you have a finite
amount of time and capital probably.

So like your time, a developer's time,
if you're hiring someone to build

something, you have an in, like a
limited amount of money to spend on it.

And you really in general have a
limited amount of time to prove.

Like a thesis, you know, you're
building something that may or

may not be what a customer wants.

And so what you really have
to think about is should this

be a core competency of yours?

Like, should I be doing all
of my own payment rails?

Should I be doing all my
own Twilio, like SMS stuff?

Or I guess the other way to
phrase it, like, is this what

a customer's hiring us for?

Right?

Like if your tool.

Is for like in the case of orbit,
managing a community, but then we do

like 10 other things on top of it.

Well, it's like maybe we need a few of
those 10 things, and so it makes sense

to do, use a gem or use an open source
library for those kinds of things.

Whereas the core competency of ingesting
events and identifying members and

that stuff should be like our core
competency is thinking about like

what your unique value proposition is.

And so again, like if you're not an
email company, probably don't send, don't

try to be the best at sending emails.

Let's send Grid do that for you.

I think Stripe is really interesting
place cuz most people can't go

build their own payment rails.

So it's like a really defensible
thing to be honest too.

Right?

Like if you're building a company or
you're working at a company and you

are this engineer, like I sometimes,
you know, I, we don't yet know if this

audience for Build and Learn is engineers
at a company or Indy founders, right?

You want to think about what's defensible,
and if spending a whole month on building

the most amazing reporting engine
is what you do, but then you have no

customers for your main product, that's
probably gonna be a bad use of your time.

And so looking at some of these, like
drop in report builders or drop in

query builders, or even an output to
air table, right, might be the answer.

CJ: Yeah, I think the point you made
about having a finite set of money

and time is really interesting because
I think the amount of money you have

also influences your decisions a lot.

Like if you are a startup that
has zero money and you're just by

yourself and you have a lot of time,
then you know it might make sense to

save a little bit of cash to build.

A few things.

Whereas if you have, if you just raised
like a hundred million round and you are,

you have like, I don't know, 10 years
of runway or something really great,

then maybe you're at a point where you
can buy, Or even like, I guess, yeah,

if, if you like zoom out a little bit,
now you're talking about like buying

potentially even like competitors or
acquiring other companies in addition

to just like buying software or paying
for software that you want to use.

So yeah, I guess that that
gets really interesting.

Colin: You may also not be able to hire
the people that you think you can hire.

And so it's like, okay, do we wanna
hire, In our case, when we think about

integrations, When you think about
build versus buying integrations,

it's a very, very large iceberg
of problems that are below the

surface when you build integrations.

And so you need to have a
purpose built team for it.

They need to be care and fed
for after you build them, right?

Maintenance is something we haven't really
talked about yet, but once you bring it

into the world, it doesn't just exist.

You gotta take care of it.

You gotta maintain it.

. But you may not when you're first starting
out, and you may not have, like, maybe

you're an indie hacker that's getting
started on your own and you don't have

the dollars, but you have the time maybe
you're a founder who's not a developer,

you may not be able to hire a developer
and so you might need to pay for an

integration platform or you know,
even hire a contractor temporarily to

get you to that integration platform.

And then that person, you know, is
gonna teach you what you need to

know just to maintain it or whatever.

It's a trade off of
time and money for sure.

And you bring up a good point,
like I do see I think a lot of

people in the reverse side of that,
like they might raise a lot of.

Build a whole team and then also
build everything from scratch.

And now you're like moving pretty
slowly because everyone's building

and reinventing the wheel again.

Whereas things like email, I'll
just keep coming back to that.

It's like, that's a solves problem.

Let's not figure out how to
send emails all over again.

And figure out again, what kind of
no code or like, really, I think the

guiding principle for a PM or, or
even an engineer would be to speak

up if you think like, This, You know,
a customer at the end of the day is

not gonna be like, Wow, I really am
glad I use Stripe for their reports.

Right.

, Right.

Or like, Oh yeah, Stripe really
sends those emails really well.

Like, that's not what people remember.

Sure.

It's important that the emails get
there and the reports are there,

but they're not, you know, as
worried about where those came.

CJ: right?

Yeah.

Would you like, I, I guess I'm,
I'm wondering if there's like a

rule of thumb here, and I'm also
nervous by the possible answer being.

Default to always buy because
that doesn't sound fun to me.

. But like I wonder if the answer is like,
by default, you should probably hire some

SAS to do a job for you, unless it is
like the unique thing that you're building

and you should buy everything else.

Colin: That's interesting
thought experiment because.

In our case we did for
building integrations.

We'll give a real use case here.

We have integrations to like
four community tools or four

or five when we started like
GitHub, Slack discourse, discord.

There was something else in there and
we knew that we built all those by hand.

So that was, we started off with
built and to get to the next 20.

We were looking at whether
or not we pay for these.

There's now services that are like a
integrations like Stripe type platform.

And so we evaluated a lot of them.

They still were gonna require
a lot of work on our end.

Like you're building to their APIs,
you're building them into your product.

Can you switch away from them?

Switching costs is gonna be an issue.

Theoretically, they're all like,
Yeah, you could leave at any time.

It's like, well, once people have
authenticated with us, there's

no way that they're leaving.

Like, we can't just make everybody re off.

So it became a situation
where like the, the.

Spoiler here is that we went with
built, and what we did though is that

we decided to look at all the five
integrations that we had already built,

and we came up with the common framework
amongst them, and then we then were

able to build, I think we now have,
it took us like a year to build five,

and now we have in like six months,
another 10 because of that framework.

And that framework was not,
You know, it was very mvp.

It was, we've been adding to it
as we add each new integration

that has like a little edge case.

And again, like every one of
these is like, Oh, of course this

company has decided that OWA works
this way And so you're almost

trying to create this standard.

And the issue is, I think like IBM
has this old ad of like the universal

business connector and it's like a
giant plug and it's got every plug on

it and like that thing doesn't exist.

. But in the same vein of this conversation,
there's this phrase in the industry

called no one ever got fired for
hiring IBM or paying for ibm, right?

Is that like, if you choose to do build
and it's wrong, oftentimes people lose

their job or the company lost a lot
of money, or they just lost a lot of

time and they still could go back and.

, Right?

It, or in some cases I've
seen people will do both.

They will build and they will buy,
and then they'll pit them against each

other, and then you can keep moving
forward with whichever one wins.

And maybe you decide that they both
win and you keep both of 'em in there

and they make you go faster that way.

CJ: That again, comes back to that
default, should you default to buy.

And I'm also trying to think about
like, have I ever regretted buying.

Something instead of building it.

And I don't think I can think of a single
instance, but I can definitely think of a

bunch of stuff where I built my own hacky
thing and it was fragile and broke all the

time, and I was super frustrated with it.

And then ultimately at the
end of the day, just like, you

know, threw it away or whatever.

So

Colin: That's interesting.

So like how much of that
was like a maintenance over.

CJ: A huge part of it
is maintenance overhead.

Colin: Like, think about Heroku, like what
you get for a paid Dino is a DevOps team

and deployment and simple tools, right?

There have been things, there's a
tool something called Doku, D O K U.

It is a docker version of Heroku
that you can spin up on your own box.

To call it a direct replacement though,
like it doesn't have, I think I, I

don't know if it might now, but like
rollbacks and like all these features

that, that Heroku has added over time.

And you just couldn't, like, as a,
especially as a single developer,

like you couldn't get that much
power even if you did build it right?

It's like if you do that, you're
not building the thing you set

out to build in the first place.

You're now building a
Heroku competitor instead.

CJ: Right.

Yeah.

And if you, if you think about
like a lot of these other companies

like Versace or Super Base or Yeah.

Like where they're enabling you to do
things that you wouldn't have been able

to do before, like deploying all these
things to the edge and you know, like

having all kinds of automated systems
for managing all of your assets for you,

your images and whatever, like there.

Yeah, I, I think the gap between host it
yourself, just like spin up and like your

own thing on Amazon and host it yourself,
like that is starting to go away, right?

Like there's all of these porcelain
beautiful solutions on top of AWS that

take away so much of the work that you
would otherwise have to do to build up all

of your own infrastructure inside of aws.

That for me, that seems like the
best example is like, don't use, I

don't know, in, in my experience, I
don't think I Should build on aws.

Instead, I should always just buy
something that is going to give

me like a nicer interface into
AWS and do other things for me.

Especially because it's, it's like even,
even these layers, these thin layers

like Heroku cell, nullify, whatever, they
themselves are also being commoditized.

Like they're not that much more expensive
than just doing it directly on aws.

And so sure they can take a sliver of
my tiny little startup, but like at the

end of the day, that doesn't matter.

A ton,

Colin: Well, and they're counting
on you getting big, right?

So they want to give you credit, they
want to give you a free site on Netlify,

and they hope that you need their,
you know, whatever their paid services

are once you like get to that scale.

This kind of brings up this
concept of innovation tokens.

Have you seen this blog post?

I'll have to find it and
put in the show notes.

CJ: I don't think so.

Yeah.

What is.

Colin: So this is essentially
like, Let's just pretend that

you only have three innovation
tokens and you wanna spend them.

You don't get to build your
own database from scratch, Write

your own programming language.

And some the third thing, like you get
three things that are novel and new,

but you can't spend them on everything.

And this is where I think you see some
startups today, like Jason Warner

previously of GitHub, he's, he's been
pretty public about like, if you're

a series a company and you're using
Kubernetes, like you probably have built

that monorail that you were talking about.

Like you probably have created complexity
for yourself that is not needed, right?

Like, why are you using Kubernetes
when Rails on Heroku should be

able to get you to product market
fit and customers paying you?

It's like, Oh, now our
API can't handle it.

So maybe now it makes sense to go to AWS
because the traffic through Heroku like,

We'll just give a 32nd time out on Heroku.

That's a problem for some people, right?

And it's like, well, why?

Why is our API taking 30 seconds
to return in the first place?

It's probably a better question,
but like it, there's a point at

which it makes sense to go down
to the rail, like the literal bare

metal of AWS or whatever that is.

But in this case, it's like, okay,
we're gonna spend an innovation

token on Kubernetes and we're
gonna go do microservices.

It's like, okay, now we just spent two.

And the complexity of the
code base is so out there.

That now onboarding a new
developer's hard, knowing how

to add a new feature is hard.

And so you wanna make sure, and
I think that it's captured better

in the blog post, so I'll, I'll
put that in the show notes.

But it is just a good thing
where it's like, let's just

say you do have five features.

You can't reinvent the
wheel for all five of them.

And.

I would even argue maybe you don't
reinvent the wheel for any of them,

like you said, like default to buy.

Like, and again, buy doesn't
mean spending money here because

you could go grab a gem, right?

Like it doesn't make sense to
build your own markdown, Previewer.

When there are 20 in Ruby alone, right?

So like, let's go use one of those.

Because again, like someone might wanna
use Markdown, but like, you're not

a Mark unless you're a Markdown app.

Like, then I would say maybe we should
make your own Parer, but like, only if

there's a compelling reason to do that.

CJ: I think it's, it's been
interesting to see from the inside

of Stripe how much stuff we've built
like ourselves instead of buying.

A great example of that is Mark, Doc.

I mean, when you mentioned markdown, like
this spring to mind, Mark Doc is this

framework for authoring documentation that
that we built and it is a React framework.

That allows you to author most of
your content in markdown files, and

then you can build components with
React that you can then sort of

sprinkle throughout your markdown.

We found that like, okay, none of the
markdown things worked the way that we

liked it, , and so we built it ourselves.

And so there's, there's actually
like quite a few instances of

that across the organization,
but that is a really massive,

successful work that's doing that.

And so I would say that most,
yeah, like most of the time

Colin: Well, Stripe
didn't start with that,

CJ: right.

Colin: important to know.

You get you like, when I think about this
article and I just pulled it up they

talk about choosing boring technologies
and embracing boredom, and that means

like maintenance and all these things.

It's like the more things you add, it's
going to become more intense to maintain.

But in the case of Mark Docs, Stripe
has kind of always been known as

like having great docs as marketing
and great developer experience.

I'm sure if we go far enough back in the
way back machine, like it probably wasn't

always that way when it was like slash
dev slash payments or whatever, right?

Like you probably could find a doc
site that feels like any startup

today, but they chose to make that
a differentiator and that's where.

Is this our core competency and
is it our unique value proposition

comes back in because they're
like, Okay, people love our docs.

Now how can we make our docs process
better for us as a team to make that

continually better for the customer?

That one makes sense.

And it's kind of a mote, right?

Like we won't mention names, but like
there's some other companies that

don't have really great docs that
accomplish similar things, right?

So that becomes a really important thing.

And you do see c.

There's literally a company that
builds itself as Stripe Docs

as a service from Y Combinator.

Right.

And so it's like, yeah.

And it, it's almost, it looks
identical to Stripe Docs.

I'm like, well, I don't really
want strip docs as much as I

want good docs that are my own.

But it's still a cool idea.

And the fact that a whole company
now exists similarly to don't

do your own email, like at orbit
we're like revamping our api.

And we made that decision like
we are going to revamp the api.

We are not throwing away all the
tools that we use to do the docs

and the API and all of that because
like we already know them, so let's

just use them and maybe use them.

10% more, like there's 10% more features
in these tools, like R Swag and swagger

and all this stuff that we just aren't
using that could make our docs better

instead of like, we're not gonna go build
our own static site generator and like

we could implement Mark Docs, but like,
it's, it's a new, it's an innovation token

for us that we probably shouldn't spend.

Maybe when we're profitable and the
docs are a clear value provider,

then it would make sense to do that.

CJ: So I am now I'm wondering, I remember
playing around with the API reference

for Orbit and you can kind of like
enter in fields and test out requests.

Is that something that you
bought or something you built?

Is that open source?

Colin: That is something we bought.

Yeah.

So we use readme.io for our docs.

CJ: The YC company, right?

readme.io, Yeah.

Colin: Or even read it
might even be readme.com now

CJ: Okay.

Yeah.

Stepping up in the

Colin: stepping up.

But I think that that IO domain signals
that you're a developer company, so you

CJ: Yeah.

Colin: keep it.

CJ: I think I saw the,
they posted a hiring.

They're also hiring on like
the hacker News who's hiring

Colin: If you love docs,
it's, it's a really cool tool.

And I will admit, like I did go into
it with like, I hate our docs, like,

because I didn't realize we weren't
using enough of readme's features.

We weren't using enough of open
API features we weren't using.

And then, so like in, in some cases
it was like, let's just re-look

at the tools that we have and we
are paying for it, but it's also.

I don't have to think about
where the docks get deployed.

They just exist.

You know, that also means like we also
wanna build out more of like what you

guys have at Stripe with the more like
guides and tutorials and stuff so that

people get a better sense of the concepts.

And they do have that in Readme.

We just don't use it.

And so like we have a whole separate web
flow website that does that right now

and like we're just gonna put it all in,
read me so that it's all in one place.

And.

Again, like we have to invest in writing
and copy and documentation, but we're

not gonna blow an innovation token on,
you know, building a Jam Stack website

and pulling in from yard docs and all
this stuff that we could pull in, but,

CJ: So it seems like the takeaway
there is that if you are going to

buy, it's worth investing in learning
about the thing that you bought.

So that you can actually
take advantage of it.

I think that's like where the
entire industry of customer

success like came from.

It was like, how do you make sure that
you increase the adoption of all the

different features and the attach of
all different features for your product.

So yeah, that's definitely something
to keep in mind, I guess, like.

Colin: Well, I, I imagine like.

If I was using one, like I signed
up for Stripe and I used the one

thing that I cared about when
I joined, I may not be paying

attention to all the other features.

Right?

And so that's where I think
CSMs can help and be like,

Hey, we know you're using this.

Did you also know you could do this?

And your team is really
great at that, right?

As you roll out these new beta
features and stuff, you're.

Looking at who's using similar
features and saying, Hey, do

you want this to be 10% better?

Come check this thing out.

And it almost always is like, this
is the thing we've been waiting for.

Why hasn't strip do this?

And it's like, Oh, here it is,
you know, for you to try out.

And with Readme it was more of, I was
like, why can't I just write in here?

Like we, we deployed to Js o
and Js O gets ingested by Readme.

And then that, and we'll do a whole
episode, I think, on docs for sure.

But.

Why can't I also put like written pros
in here to help developers understand

and maybe even drop in a video or, you
know, a, a diagram because the open API

spec, to my knowledge, doesn't have that.

Right.

And does that belong in the
code and all that stuff.

But then I was like, Oh, read me, has an
editor right here, and if I write in here,

it shows up above the generated stuff.

So it's like, We, that was like a
light bulb, but also like, wow, how

did we not know that this was here?

In our case, maybe we
have a CSM with readme.

I don't know, maybe we're not
paying them enough for that kind

of attention, but like it's just
nice to like get into the tools.

You have what you mentioned
about defaulting to buy.

I think that's a smart thing.

Like I would say definitely
don't default to build.

At least go get a spreadsheet.

Do a little column, pretend you're
buying a car, you know, and figure out

like, if I do this, if I do this, if
I do this, And I would also ask like,

what would, what, what could go wrong?

Like if this, if we get this wrong.

Is it the end of the company?

Is it, am I gonna get fired?

, Right.

Hopefully you're in a company that
celebrates learning and failure

and you're not gonna get fired.

But I think making sure that
everyone knows, like what

the stakes are, is important.

And then the other side of
it is what could go right?

Like if we pull this
off, how great is that?

And you know, for us, building
integrations has, I think we're still

gonna wait to see if it pans out as
being the right choice, but like, If

we had to continually pay more and more
and more money to companies based on how

many people are integrating, it feels
like a good value metric to go off of.

But like, you know, when time, like right
now with the economy being what it is, I

think we're really excited that we don't
pay more money for our integrations.

Like the, the other way to think of buying
is that you're renting versus owning.

And as a homeowner, you know,
like owning a house means

taking care of the house, right?

Rent.

Sure it might be a little bit more
expensive per month, but you're

not taking care of the house.

You're not having to deal with
all the stuff that goes into that.

CJ: So that reminded me of another
concept, and I'm curious how

you're thinking about this, and
that is around platform risk.

So if you decide to buy and you go
all in on a platform, and then that

platform either just like increases
your prices, By some crazy amount

or they discontinue a service that
you're using and depending on, or

that your entire business is built on,

Colin: Or they go outta business.

CJ: right, or they go outta business.

So maybe this is like another potential
warning for buy is try to validate the,

I don't know, like make sure that the
company you're buying is legit . The

software you're buying is gonna last.

Colin: Yeah, you kind of hit
all the heads there for that.

Definitely consider that as a risk.

Technically, if they're building and
growing as they should, they're trying

to get the word that they'll never use,
but it's called vendor lock in, right?

They want to provide you more
value so that you willing,

like you gladly pay for it.

But it does mean it's going to be harder
to leave one day, and maybe that's okay.

That's just something that
you have to kind of think.

CJ: Mm-hmm.

Colin: When I was building, I was a
Techstars company called Cloud Snap,

and we were building an integration
platform as a service back in 2012.

We only had raised $500,000.

So how many companies do you think were
willing to put our code into their code

or to talk, you know, to build to us and
create those integrations that we required

you to kind of follow a little bit of
a stripe model for like, We're gonna

give you a customer token and, and we're
gonna hold onto all their oau tokens and

we'll handle refreshing them for you.

And it's kind of like a
credit card in that respect.

And who, Yeah, not a lot of companies
were like, it's like maybe if you

guys go out and get your Series
A, then we'll, we'll chat again.

They just wanted to know that we
had the runway to even exist, let

alone the technical side of that.

CJ: Yeah, that's interesting too
because it, when, when you were

building clouds snap if I recall
correctly, like one of the first

integrations was sale Salesforce.

Is that right?

And so I'm in the back of my mind.

I'm like, I wonder if going for
the enterprise integrations first.

Was something that caused the companies
who would use those enterprise

integrations to question versus going
for like more indie stuff first.

I have no idea.

Yeah, exactly.

Like it's also interesting because
I feel like where you're at now, And

Cloud Snap and my VR and like a bunch
of tools that we use are all like very

similar in that they live at the seams
between two giant systems or like between

lots and lots of different systems.

And yeah, like there's definitely so
much value in being that glue layer

between all these different useful tools.

But yeah, trying to figure out how
to build a company around it is

definitely challenging for sure.

Colin: Yeah, I think you and I
might be gluts for punishment there.

Like being on the seam is a
pretty terrifying place to be

like, cuz things are always
breaking, things are always trying.

It's like a multiverse of apps, right?

It's like

CJ: Yes.

It's, yeah.

It's like choosing to build a
house on the San Andrea's fault,

because like everything is around is
shifting and like maybe your house

is gonna fall into the sinkhole.

Who knows?

Colin: But it's something
that a lot of companies do.

So anyone who solves it, you know,
whether it's internally, like at

my vr, it was trying to figure
out how to do that for themselves.

But for us it's like, Oh yeah,
customers build your houses

on the San Andreas fault.

We will handle all the issues.

And you're just like, We can't

And I think that there still is,
like, I still think that integration

as a service thing is interesting.

There are a few companies doing it today.

Kind of, are they how I would do it?

No.

Like that was the ultimate reason why
we didn't go with them was it required

our team to know their tools so well.

So it's kind of like, Do we wanna
become consultants of this tool?

And then if those developers ever leave,
now we have to train someone else on it.

Whereas what we ended up doing
kind of to round it out here is

everything we built is in Ruby.

Every one of our engineers
is a Ruby engineer.

Everything is not in unfamiliar to them.

We can do code reviews, we can check it.

It's not like talking to some.

Thing on the other side of the fence
that we don't know if it's gonna go down.

We don't know if how it works.

We don't know if it's gonna go outta
business, like all those different things.

And that was where I kind of ended my
talk was that it's at the end of the day,

it's Ruby, It's Rails, it's convention.

It's a lot of different things
that like we're used to.

And so we don't need to reinvent the
wheel every single time we do it.

But we also do get some satisfaction
outta getting to build it ourselves

and own it and invest in it.

So yeah, integrations.

All right.

So I think that's a great place to wrap.

We hope you enjoyed our deep dive into
build versus buy, and you got a little

bit of Burning Man envy as well.

CJ: Right on.

Next time we're gonna be back
talking again about code reviews.

This time talking about how to review
code rather than authoring a pr.

And as always, you can head over to
build and learn.dev to check out all the

links and resources in the show notes.

Colin: That's all for this episode.

We'll see you next time.

CJ: Five friends.