Build vs. Buy

Show Notes

Colin's RailsConf 2022 Talk - 
Innovation tokens blog post - Choose Boring Technology

Full Transcripts

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 for our docs.

CJ: The YC company, right?, Yeah.

Colin: Or even read it might even be 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 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.