Build vs. Buy: Navigating Software Buying Decisions

Why is the layout fucked up?

I switched it a minute ago because it was like ultra zoomed in. ⁓ So ⁓ when you do that on my screen, this is what I see. I'll take a screen shot because I've got the screen cut in half. ⁓

So. ⁓

Mine's 50-50 as well, Gary, now.

you

that this is what I see.

like ultra close up.

⁓ could you have it like your screen 50-50? ⁓ well maximize it.

⁓ Yeah. ⁓ Well then I can't see my notes. ⁓ That's better.

up to me. I no goddamn notes. Actually.

Uh-huh. I've got, I've got all the examples of the things that we've built. And I wrote, we've got an Nimbus component library, Nebula, Jarvis, Ascon catinator, ⁓ RFPAI thing, Reggie, Booker. ⁓

Okay. Put it in the script then. In the studio you can say, and put it in the script and then have it... Boom. Shit.

I mean I just had it over in the finger bobber.

I know man. ⁓

That's weird. Why is it carrying over my University of Arkansas script? ⁓

because there's one, the studio.

⁓

This is, ⁓ there's not a studio per recording. It's the studio that you do recordings in. Which in some ways I do actually appreciate that because you know, if you get the studio set up the way you like it, shit is just set that you don't have to do it every time. It's just like, you know, even the brand stuff that has like our little tags or like what our name and whatever at the bottom left here, like all that shit set from exactly the way that I had it before.

it's this.

Mhm.

Yeah.

⁓ That's cool.

Which ⁓ I think for ⁓ purposes of like exporting stuff, ⁓ we need to come up with some sort of, we'll dig around with it, but.

We want some sort of like the ⁓ words over the text, right? Or over us. ⁓

We already have it. It has our name over us.

I mean, yeah, that.

You're talking about captions? Yeah, that's it. That's built into you. hit the captions button. I mean, you won't on the podcast record on like the long form recording. You won't on the short form you do. Yeah, if you just turn.

Yeah, that.

Right. Right. We just need to get a style for that that we like. Which now that we have ⁓ a color palette, then we'll be able to use it from there.

Yeah.

Yeah, that makes sense. We're gonna need to get some some options for this because this will be fun

What?

⁓ like just ⁓ as we're talking to stare it in.

soundboard.

You hear any one of those ⁓ freaking Elgato ⁓ wave things, ⁓

Yeah. ⁓

all the things we can do. ⁓

Your money.

Well.

When do you want to get started?

I'm ready.

All right. Do want to do like the welcome back bullshit or not?

I I don't think so. ⁓ I honestly think that's one of those things that like when you watch like YouTube videos a lot I feel the same way or like I've done it like go to if you go to like people's tik tok streams especially like newer people you'll notice like they they start with the same fucking thing every time and like on one hand it makes sense like if you're like welcome back blah blah blah blah like

Yep.

Welcome back you motherfuckers ain't watched a single fucking episode. This is your first episode and Also, you probably know you're watching the whole fucking episode You're probably watching the few clips that we posted somewhere and like maybe a little bit more so

Ha ha ha ha.

Yo. All right, so then ⁓ we'll start with.

I it's think it's honestly think it's easier like we can just be like alright today we're talking about ⁓ like today we're talking about building versus buying something we've done before and then we just launch into it from there and it's just like whatever ⁓ get fucked. ⁓

All right, let's do that. Cut. we go. Today we're talking about build versus buy. And when we say build versus buy, we're talking about essentially software could be other things that you have in your business. But from our perspective, it's like software oriented needs, things that solve problems that are recurring things in your business. And you're like, shoot, I got to solve this. I'm not sure exactly how to solve it. Do I build something on my own? Is there something in the marketplace that already exists that I can go buy that solves most of the needs? ⁓ And this is a really, really thing near and dear to our heart, because over a long period of time, we've done both. ⁓ We bought lots of different software to solve needs and then we found that ⁓ some of that software didn't solve the needs the way we expected or lots of broken promises along the way and we had to go down a different path and that was ⁓ down the path again of build versus buy. So today you're gonna hear a lot about ⁓ perspectives that are probably different ⁓ from Ryan and I where We go down the path of build versus buy partially because of our skill sets and perspectives and partially just because of ⁓ our experience in ⁓ past lives. So with that, Ryan, perspective, what's the hot take? Do you build? Do you buy? Is it an always solution? Is it a sometime solution?

I mean, I think it's definitely a sometime solution ⁓ and it varies based on organization, right? Like when we had the concept of this idea to talk about it, we're ⁓ talking like our barometer, I think, is maybe a little bit skewed in terms of like build versus buy, but it also is based in ⁓ what we have the ability to do, right? We have a lot of highly technical people. We have a ton of technical expertise. We've solved hard problems. We've built software for clients for years. So when I see a problem, it's like, we can build a purpose-built solution that solves this problem exactly the way that we want it to. Or we can buy this piece of software ⁓ where a salesperson promises me it solves the problem. ⁓ It's a big, ⁓ depends, right? I've yet to purchase a piece of software that integrates, that every one of them have claimed that they integrate with QuickBooks ⁓ and that everything's all flexible and it'll work perfect. And not a single one of them has ever worked with QuickBooks. At least not with our QuickBooks. ⁓

not in the way that we would have expected it to work anyway. And ⁓ I think that's true across probably most software systems in pretty much every industry. So if you pick on like core functionality pieces, so accounting slash bookkeeping, ⁓ CRM oriented things. ⁓ call it project management, communications, those sorts of things are kind of four or five pieces that almost every business, no matter what industry you're in, have to have in some way, or form. And yet for some reason, even in those big buckets of things, the available solutions that are out there tend to be a bag of tricks, not a bag of solutions. Where you get into it and it's like, hmm, this isn't quite what I expected it to do. Or like, why doesn't this feature exist? Wouldn't it? Wouldn't that make sense? I mean, a perfect one for us to just pick off right off the bat is like QuickBooks is one of the largest, if not the largest, accounting and invoicing softwares on planet earth. They support primarily small businesses in a lot of those small, small mid-sized businesses. And in a lot of those businesses, they have people in workflows that likely have to happen before something actually gets invoiced to a customer. And yet within QuickBooks, there is literally no solution. for ⁓ invoice approval processes. There was no work around other than saving something as a draft invoice, in which case you have to have somebody that has access to your QuickBooks platform, which we didn't want. We're like, we want our account team, our account management team to be able to put together a draft invoice and say like, all right, somebody else look at this, ⁓ approve it, and then it'll go to the QuickBooks system and then do all its things. So perfect example of build versus buy. So say more about that, because you freaking built it.

Yeah, that's our It's like 10 years old now, I think 12 years old started as like a rails 3 application and was my first rails application actually, but Yeah, I mean in that example we had we had a problem of wanting to be able to go through an approval process and tie that to some some things and make that something that Could happen outside of the accounting system but then flow into the ⁓ accounting system and maintain that link and share back information. ⁓ And ⁓ I mean, we looked around for a long time. We've tried project management software as the claim to do that. We tried ⁓ looking within QuickBooks itself and none of them really ⁓ had any of that option. And ⁓ it's a very simple workflow. ⁓ So we stood up an app. that just does that, right? ⁓ It does exactly that. It's a ⁓ very small Rails app that you can, ⁓ that we can pull in information from our project management system, like time tracking information and that kind of stuff, choose how to build that out. ⁓ It pushes back into our ERP ⁓ and pushes into QuickBooks and everything stays in sync and it's all great. And that's an example of like, you know. again, we have the benefit of having the technical expertise that we could just see a problem solve a problem ⁓ and You know, I think it took like a week or two weeks ⁓ to get the first concept out the door ⁓ And now we have a purpose-built solution that solved the problem exactly for us it wasn't you know trying to buy this massive system that does Everything for everyone and hope that it does it. ⁓ Well, it's exactly the it solves exactly the problem that we had and ⁓ has done it really well for a long time.

Yeah, not without its bumps and bruises over time, ⁓ But I mean, that brings up another point. So we built that system. And over time, needs associated with it have evolved. It started out as just a very simple invoice approval workflow. ⁓ And then we built like this, ⁓ you know, ⁓ billing burn down sort of chart thing to say like, okay, let's compare how much we should be billing this month with how much we did bill this month ⁓ and draft invoices, et cetera, et cetera. So we've had lots of different tentacles, I'll say, that we've gone down the path of with that. ⁓ QuickBooks approval process.

I think that's you you kind of bring up an interesting point with that too like the ⁓ especially if you're gonna go on the buy side of Sorry the build side of things I think one mistake that a lot of people make when they go about building any product, especially an internal product ⁓ and we've fallen victim to it too. I'm hoping we haven't ⁓ is ⁓ ⁓ Is trying to make it too too much right? You're like, alright. Well if we're do this, we've to design everything about it We've got to get all the requirements. We got to get buy-in from everybody make sure the whole fucking thing is perfect and then go off and spend a year building it and then we'll see if it works ⁓ and ⁓

My sign. ⁓

Yeah, mean that's a good example and What we've found is iterative development iterative development is the way to build any sort of application Especially for yourself because your requirements will change as soon as you put in the hands of users so in the example of the Invoicing request system that we call Jarvis You know, yeah

Yeah.

Don't come after us, Marvel.

It was, ⁓ you know, we created it, super simple, it was very simple concept and as soon as we put it in the hands of the team, you know, we solved a problem but then people start asking like, well what if, or could it do, ⁓ or could we also? And then you start adding in those layers, right? It's like, could it also push this to our ERP so that we could see the billing progress in the ERP platform? Well yeah, it can actually. ⁓ You know could we ⁓ show a chart inside of here so that we know how much we have left to send and in terms of invoices this month Forecasted versus how much we've already sent. ⁓ Yeah, we could ⁓ But trying to predict the future and predict all of the problems you're gonna solve You kind of have two things happen one. You don't get to use the fucker until forever because you're trying to boil the ocean but Secondarily, you're probably gonna build some shit that you find out like kind of sucks and because you You never got it in the hands of people early to figure out that it's just not a good feature or it's not a good idea You never got to throw it away in before you built the whole thing

Yeah. mean, in, building a solution for a business, you almost have to treat it like its own little mini startup, right? So ship early and often get it in front of users, get feedback, make sure it's actually going to solve the problem you think it's going to solve, iterate on the user experience and the design and the future requirements sets. But I think equally important is protecting the integrity of what it was meant to do in the first place. So to your point, when you build a custom solution, like in this case, an invoice approval process that ⁓ we think is missing from QuickBooks. Come on into it. ⁓ That should be something pretty native at this point. ⁓ But ⁓ it doesn't exist. And so ⁓ what we tried to do over some period of time ⁓ was we accepted all the what ifs ⁓ as ⁓ we coulds ⁓ and we had ⁓ scope creep on our own project over some period of time, right? And all for well intentioned purposes. And actually that's one that I'm gonna go on the other side and say like, We were building things that other solutions off the shelf actually did better than us. And so we were trying to build things into this purpose built platform and system that did its job, did what it was supposed to do. And instead we were like, let's take a pause. Let's go and look on the outside and say like, what other problems do we have? And what could, what could, what could fix those problems? And then just integrate with this purpose built thing that, that does what it does really, really well. And so that's when we went on the exploration of essentially a new ⁓ project management platform for purposes of maintaining budgets and burn downs of invoicing and all these sorts of things, because that's what they do. That's what that software is purpose built to do. Does it do it perfectly? No, but my rule, I don't know about your rule, my rule is 80-20. If it does 80 % of what you need it to do or want it to do, can you live without the 20? If the answer is yes, ⁓ then that's probably a good thing to purchase.

Any questions?

And if the is still important to you, then you ask the question of, can I integrate it with something else that already exists, ⁓ or can I build something alongside it to fill the 20 if that 20 is really important? ⁓ So that's sort of how we've ⁓ loosely solved the build versus buy problem for ourselves over a long period of time.

I mean, I think the hardest thing, ⁓ well, ⁓ kind of two things on that. I agree with you. ⁓ If you have a problem that needs to be solved really quickly, and ⁓ it's not hyper specific, you're probably better off to buy a solution, right? More often than not, because no matter how easy something ⁓ seems, ⁓ ⁓ It'll always take longer to build it than you think it will. We've built some stuff crazy fast, but you know, then they start to creep and you find the edges and whatever. ⁓ There are plenty of things and there are plenty of things that we have in our business that I would rather just stitch together in innate end workflow ⁓ or ⁓ use some off the shelf solution like a jot form. ⁓ is just there, right? Like it just works. And ⁓ I ⁓ can ⁓ concept it in the morning and put it in use in the afternoon, and it's ready and it's production grade and it's gonna work. And ⁓ over time, perhaps you ⁓ build something that solves the hyper-specific ⁓ aspect of it. ⁓ But mean, hell, we've run... ⁓ an entire Airbnb business basically on the back of ⁓ a chatbot that's ⁓ just a bunch of innate workflows ⁓ integrated into previously Slack, now Basecamp, Campfires. like that has revolutionized how we manage ⁓ a totally separate business that we have from the marketing business. ⁓

Yeah. So, so just say, to say a little more about that. like in, the Airbnb businesses, which Ryan and I have several together, ⁓ do you, have a constant problem of communications with guests. so you have lots of these particular homes are very large homes. They ⁓ have 20 plus guests that can stay in these homes ⁓ and you have lots of people coming and going all the time. This community also has gate access. So every person that gets into the community has to have a gate code to get access to it. So with all of that comes a lot of communication with all the people about these are the problems I'm experiencing and it's the same problems over and over and over. But also like, Hey, it's, you know, nine o'clock at night and I need to register somebody with the gate and lo and behold, this little gate access thing for the community is not an easy software. It's a terrible user experience and it takes way longer than it should to do what you would expect it to do. And so with all of those things in mind.

always

What Ryan's talking about this, this, this NNM workflow that he created, call it Booker and Reggie, two different agents that work together to solve this problem. One is answering ⁓ common questions that we can farm out to ⁓ a, ⁓ a virtual assistant. So they can ask questions in, ⁓ Basecamp to ⁓ Basecamp Campfire and talk to Booker and say, Hey Booker, the, ⁓ the, the pool's not heating. What can I tell this guest about the pool not heating and Booker will come back with all the previous responses over the past six or seven years ⁓ and be able to tell you what the common responses are. Copy paste boom. Now the virtual assistant knows how to, how to do all those things. Reggie does the same thing, but for gate access. So we can tell Reggie or Booker in the campfire. And he talks to Reggie and says, Hey, ⁓ I need Jim Smith to be registered for Ryan's stay ⁓ at, ⁓ at this gate. And Reggie and Booker know what that means and know how to go figure it out. So saved us literally probably hundreds of hours in a given year in terms of, of our time of doing these things and managing these things.

yeah, I mean we just had one the other day that the, ⁓ you know, the gate access system, I don't even think I told you guys, ⁓ the gate access system got wiped at the, ⁓ at the guard. So all of the people that had been registered over the course of two days during Thanksgiving were wiped. So we had to re-register everybody. And we had ⁓ three guests checking in all in the same day. Each one of them had probably 18 to 20 people on their guest list because they had a bunch of people staying and they have some people visiting. ⁓ And that would have been, ⁓ that was an absolute nightmare already, but having to individually register all of those would have been an absolute nightmare. But being able to just like pop in, just send a DM to Booker and be like, ⁓ Booker. re-register all of the guests for this reservation, this reservation, and this reservation. And then Booker fires off to Reggie and says, yo, register all these things. And about three minutes later, they come back and they're like, here's the guest list for all three of them. ⁓ You can't beat that. And especially as we thought about how do we scale this business, how do we delegate pieces with it. There's so many pieces and parts and nuances with these houses. mean, they're eight bedroom, five bathroom houses with pools and spas and game rooms. And there's just so many things that could go wrong or questions that are asked or ⁓ things. But because Booker is seated with a rag. ⁓ of basically all of the questions and answers that we had answered over two years, ⁓ he knows the answers. And we're able to hand that to an assistant. ⁓ And if someone says, hey, is there a grill at the house? She's never been to the house. But she can ask Booker, and Booker knows the answer. And Booker knows not only that we don't have grills at the house, number one, because it doesn't add any value, and it's a liability, and they don't get cleaned. ⁓

That's a whole thing. ⁓ But she can say, are there grills at the house? And Booker will say, no, there are no grills at the house. However, Otter Equipment ⁓ is a local company that offers free pickup and delivery. And we've had a lot of guests use them that really happy with. So it goes the extra mile of knowing exactly how we've responded to that every single time and layering that in to either help us remember what it is that we should tell the guest ⁓ or just straight solving the problem by itself. ⁓ We haven't gone the route of having guests communicate directly with Booker ⁓ just yet. It maybe won't, right? Like there's still some aspect of ⁓ Airbnb as a hospitality business. And I think there's an element of hospitality that needs to remain somewhat inherently human. But I think being able to optimize and streamline the way that we're able to handle those. has fundamentally changed things, especially for those, you know, who are standing in line at Disney World and somebody says, hey, I need to get this guest on the list. We're like, okay, cool. ⁓ At Booker, register this guest ⁓ and it's taken care of.

Yeah, and I think ⁓ it's an interesting.

That is a good example of build it. A, that solution does not exist ⁓ that I know of anywhere. And B, we had a hyper-specific problem. Our system is this gate access system. There's no API. There's no integrations. There's no tooling around it. ⁓ mean, hell, the way that we're interacting with it is because I reverse engineered their mobile API that technically isn't public. But it works. ⁓ So ⁓ we were able to find a very acute solution to a very acute problem. And that is the situation where not only should you build it, you have to build it.

Yeah, I think we should let Booker loose on after hours as a test and just see what happens. Like if it's after 7 p.m., let's say, then you only talk to Booker. We just make it clear, like, hey, you're talking with an AI right now, so be gentle. We'll communicate with you during normal business hours starting at whatever time the next day.

Yeah.

Yeah, we could. I mean, it the alert mechanisms and things built into it that help because it does some other stuff too, like managing. You know, if somebody is a last minute check in and letting our property manager know, like, hey, we've got a last minute check in, adding it to the cleaning list, all of these things that we have to do every time there's a new guest or guest cancels or somebody needs to be registered. There's like all this stuff that has to happen. And none of it is particularly difficult. But it's very tedious, it's very timely, ⁓ more often than not. ⁓

Always seems to happen when you're at dinner or out and about somewhere.

Always. ⁓ There's always the last minute guests that register when you just sat down for dinner out at a restaurant for the first time in a week. ⁓ Yeah, every single time. And they have like 20 guests that need to be registered and they're at the gate right now. ⁓ So luckily we're able to just solve all that through a whole series of automations that we've built.

Yeah.

And, ⁓ you know, I want to go the other direction and say, sometimes ⁓ what you build evolves over a period of time. ⁓ And so ⁓ we have one that we now call Nebula that started out, ⁓ actually took two different forms. ⁓ It's a media planning solution. ⁓ Our, our business Oodle is heavily into media and marketing management. And so we needed solutions to help augment a bunch of things that we were doing in spreadsheets and in air tables and in emails and a whole bunch of other things. But that didn't start as a huge solution that kind of consolidated all this different work and workflows into stuff. It started out as like, you know, ⁓ a prototype built in a spreadsheet. ⁓ And then the spreadsheet evolved into an air table and the air table evolved into, ⁓ you know, ⁓ I'll call it a small version of like media planning. And then the media planning piece grew into communication with clients and then the communication with clients grew into Hmm, we can do media reconciliation that connects with our QuickBooks platform ⁓ and, ⁓ and also has creative built in and, what if we just added a creative, ⁓ a creative solution that you could actually build creatives within the ad and, what if we added the, the reporting and, and visualizations into this thing? And, shit, now we have a really powerful solution set. What if we added some AI on top of all three of these components planning, creative, and reporting? and allowed us to maximize those things. What does that do? Oh my God. Now we have this wonderful solution that allows us to be 50 % more efficient than our competitor sets at doing the same type of work and also more accurate with doing the same type of work. So

an interesting one because it's like a build to buy to buy to build to buy to build kind of path right like the original Nimbus product that we created was in 2015 2016 somewhere in there which really was you know we had the same problem that we had had already like getting a

⁓ Pretty much. ⁓

Sounds right, ⁓ 15, 16. ⁓

keeping track of approvals for ⁓ ads and social posts and those sorts of things is difficult. ⁓

For anyone that's ever experienced that workflow, and it still exists this way for most organizations, what happens is you create a bunch of ads or a bunch of creatives for organic social. And usually you're not doing like one at a time. You're doing 10, 20, 30 of these things at a time. So you're doing them in big box. And so you either communicate those things in a big old spreadsheet or you communicate those things in ⁓ a ⁓ word document. And at least at the time, that's exactly what you were doing. And we were like, this is stupid. This is a terrible solution. ⁓ The back and forth is absolutely ridiculous. The markup and the commenting and the exports and the human capital involved with all the rework involved and the mistakes that are easily made across this journey is just dumb. So let's fix that. ⁓ So we created Nimbus as a way to visualize all these creatives in context. So you could see how the creative was going to look in the social platform, but also have the advertising pieces that we needed for tagging and flagging all these things appropriately in our systems, ⁓ all included as part of that same software solution set. And so we saw, and we had the get the client communications happening within the platform as well. So clients could see it. could, they could give feedback and comments. could see revisions that are made, give feedback and comments, ultimately approve those things all in a database platform that kind of feels like ⁓ a ⁓ a base camp like user experience. And so that's how we modeled that and solved that solution at that point. That was 2015, 16. And then it evolved.

Yeah, and then it evolved. And then we didn't have resources to maintain it. And we didn't have ⁓ the challenge as much because our business kind of pivoted for a minute. then ⁓ we decided, ⁓ surely somebody has built something better than Jake and I could build in the weekend over ⁓ Christmas break. ⁓ So we bought a couple of products. ⁓ We tried those for a few years. They sucked. ⁓ we made our way back to spreadsheets naturally, or it was like some tooling plus spreadsheets to augment it because they were just bad. And then we started toying with the idea of building again, and then we were like, well, I don't know. It's a big commitment to build something like that and maintain it long-term. So we bought some different stuff, and then ultimately, one of the, most recently about a year ago, a little over a year ⁓ one of our team members kind of took Airtable and ⁓ spreadsheets and those sorts of things and kind of built like a little concept. I was like, this is cool, but it's still spreadsheets. ⁓ But that same individual had shown some interest in ⁓ doing some development work and learning to be a ⁓ fully fledged developer from kind of the ad side of the business. ⁓ So that's when we kind of birthed Nebula, right? It was basically like, all right, well, I'll make you a deal. We'll start building this ⁓ as an application. And if it works, we'll put it into practice. ⁓ And it wasn't long before we started handling production workloads basically ⁓ in Nebula ⁓ to the extent that now every... ⁓ ad that's planned and placed and media plan that we have goes through that platform and has for over a year. We've planned a ton of media through that platform already.

millions and millions and millions of dollars.

Yeah, I think it's like $50 million ⁓ at this point that we've planned through there. And for us, has, I mean, shit, it's reduced the error rate to basically zero. It actually allowed us to eliminate ⁓ parts of our processes because we didn't have any errors. ⁓

Just getting started.

Which is insane, right? Like I get lots of vendor IOs from other vendors and it has like a, probably like a 30 to 50 % error rate. Like there's, you know, an ad size is wrong and a number is wrong, a calculation is wrong. Like something is always wrong. And we experience that same problem. It's a lot of information. It's a lot of information to manage, you know, hundreds of plans times, you know, thousands of placements times. potentially tens of thousands of different allocations and fees and fee calculations and ⁓ what applies to what and then add sizes that are gonna run for all of those. ⁓ And ⁓ Nebula just does a really great job of consolidating all of that stuff down and giving you multiple ways to look at it. ⁓ If you're, like I was just, there's a new view that exists in it that we created last week. That's basically like my view. ⁓ When I think about our media that we're running, How do I wanna look at it? And there's certainly the super detailed view where we need to be able to see everything. But generally speaking, I kinda just wanna see how's our media spend tracking over time? Where's the split? Where are we investing those dollars? Split across different channels and formats and things. And that's kind of it. But I still wanna be able to dive into the details if I want to. And I think that's one of the advantages of building a system like we have with that, ⁓ is it does afford us the ability to say, it's not just a spreadsheet, it's not just a chart. It can be both of those, and you can offer that to the user. But again, going back to, like we said earlier, or I thought about saying, and I'm not sure if I did, the hardest thing in building anything is saying no. because your users will always, always, always request things. It never fails, they'll always request things. ⁓ It doesn't matter what you're building. The question is, does that fit within the core of the product? And we've had a number of things within Nebula, we've had things within Jarvis, ⁓ I've experienced this and working ⁓ on other projects outside of Oodle, I've been working on the Amarchi project with DHH for a while. ⁓ We've experienced with that.

Right, people ask all the time for things that they want to add and the hardest thing is looking at it and saying like, decent idea doesn't fit with decor. It's probably the reason that QuickBooks doesn't have an approval workflow. Right, because when I look at QuickBooks, if I'm the product manager for QuickBooks, I can look at that and say, yeah, can see how that, I can see how some number of businesses benefit from this. The problem is, ⁓ the moment that I accept this, this monkey is my monkey forever. So it solves your problem, but then I have to maintain this fucking thing. So ⁓ is it in the best interest in the core product of QuickBooks to maintain an approval workflow, or should we just stay focused on accounting software? And they've made the decision to stay focused on the accounting software, obviously.

You bring up a good point. Now I'm going to come at this from a slightly different angle. ⁓ As someone that does not have ⁓ the ⁓ coding ability that you do, I'm someone that often comes to you with ideas and it's like, what if we could. What, what if we did this? What if we do this? So ⁓ I like, I like the journey of the pie in the sky. What could we do? I think the part that the business side that I flip on sometimes in the build versus buy equation, which is why I have that 80 20 rule as my rule of thumb ⁓ is now every time I need something, if it breaks, ⁓ if, if there's a feature that isn't quite doing what it's supposed to be doing, any of those things is now capital that I have to help employee. whether that's you or the developers on the team or someone else to help go solve and fix. And so there's always this ⁓ maintenance challenge that happens with the build side that you literally outsource to someone else if you buy. ⁓ And sometimes that's an advantage and sometimes it's a disadvantage. You may not get the thing that you ever want, ⁓ ever. ⁓ So to your point, ⁓ in the Intuit community with QuickBooks, There's maybe a product manager that looks at our little feature request of, an invoice approval workflow. And they're like, yeah, it doesn't fit with the flow. It'll never happen. And that can be okay. And that's great for their business, but not good for mine. And so ⁓ if I want that, I have to figure out how to solve said problem for a while. We did that by way of spreadsheet oriented invoice workflows. So we did like a mock. version of the thing. And then we had our accounting people input it actually into the system after it was approved in this mock version in a spreadsheet. That's a band-aid solution. It worked for some period of time until we got to a scale and a size where it's like, that doesn't work anymore. We would like to change that workflow and now let's build something. It's worth the capital investment to be able to not only fix our problem, but also know that we're signing up to maintain that problem for the foreseeable future.

And so we abandoned that or we find a different way to do it. That's, that's now something we have to maintain. So in the build versus buy equation, coming at it from a business sense, it has to solve 80 % of your problem or the buy has to solve 80 % of your problems and 20 % you can live without. Or if that equation is flipped differently, the things you're going to buy don't solve 80 % of your problems. And you think you could get, you know, a vast, vast majority of what you need out of it by building it. Just know it comes with that. that process of maintenance over some period of time and change management when things change and workflows evolve and, and, and, and, right? Some of these natural business challenges don't get absolved if you decide to build versus buy. Those sorts of workflows still have to exist.

Yeah, I mean it's never it's never cheaper almost never Unless you're talking about like Certain products that from companies that I love refrain from bashing them today ⁓ the The build ⁓ it's almost never cheaper to build it can appear that way right you're like if we build it it's free a Free there's no fucking thing. It's such thing as free software

Hmm.

You've got to host it. If something goes wrong with it, you got to fix it. When there's a library that we find a zero day critical problem in, got to patch that library. You've got to push updates. Even if you don't change anything about the software for 10 years, there's still some amount of maintenance that has to happen. And it is not free. It might not be nearly as difficult. That's the advantage we have today is the infrastructure that exists and how all that happens has evolved so much over the past 10, 15 years. where that used to be excruciatingly painful and very expensive. But now with, you know, Docker being a thing and being able to spin up just like a VPS really easily, you could have an app, it off the shelf, deploy it in a Docker container, throw it up on a VPS and, you know, for $10 a month, you've got a solution that's hosted, it's containerized, it's ephemeral. If something goes wrong, you just reboot the fucking box. And that'll fix 90 % of the problems if not a hundred percent of them Now eventually you have to figure out like why is there a memory leak? And that cost you money But that's also a reason that like I've been a big fan of the the model It's timely with fizzy launching yesterday. They launched under what they call the OSASI license And there are other ones that have this right we use these products like Metabase is it has the same sort of model in 8n has the same sort of model where there they are source available products ⁓ That are also offered commercially ⁓ Which is something I've grown to really like we ⁓ we those two product all three of those products right fizzy and 8n and ⁓ and ⁓ Metabase are all three products that we use as a part of our business

⁓ I will happily pay for, ⁓ happily do pay for two of them and will pay for Physio, you know, now that it's out of beta. ⁓ And we'll happily continue to pay for those as a ⁓ bought solution, right, in perpetuity. However, there's source available and if the needs of our business ever reach a point where we need to do something that's outside of the capabilities of the whole. hosted platform, I have that option. And we've exercised that option. There are some things about the first generation of a Booker that ⁓ leveraged certain JavaScript libraries, ⁓ like Slackify, because Slack uses ⁓ a markdown syntax that's atypical, and it was hard to get the AI agent to format things in that way, so we used the Slackify library. that Slackify library is not available on the hosted version of 8.in. No problem. I bought a VPS, ⁓ deployed 8.in to it, and that was Booker for the longest period of time. was our own hosted version of the open source community edition ⁓ of ⁓ 8.in. And then over time, we realized, hey, if I move this stuff to Basecamp, I don't have to deal with the Slack syntax anymore. It also furthers my agenda of getting more things to Basecamp and reducing reliance on Slack. ⁓ So. ⁓ Great. And we were able to move that stuff back over to the N8N hosted side. And now I don't have to worry about if something goes wrong and the server goes offline because that's their problem. And I pay them a small monthly fee. It's not much more than it cost me to host it myself to not have to deal with that headache.

Yeah, I think there's a lot of, ⁓ there are a lot of software solutions that are out there that ⁓ are off the shelf. I can go sign up right now. Let's talk about the ones that ⁓ are behind a call behind an iron wall. We've experienced this too, right? So when you go in and you want to buy some software and you're like, ⁓ this looks amazing. This thing looks awesome. It looks like it might be able to solve my solution. There's usually like one of three paths.

the enterprise ones.

The first path is, and they almost all have this as your first path. You have to talk to somebody. like, well, I'm not really, I don't really want to talk to somebody, especially as somebody that's pretty technical, technically astute. I can, I can pretty well log in and figure it out in a hurry. Like what's going to happen. There's not really a lot of corners that you're going to help me steer around. So you're just wasting my time and energy doing that. The second path is like, now, now I've, I've got you, I'm talking to you. It's like, well, What does this thing cost? ⁓ You want to, you want to give me like, you know, the, the ⁓ run around to tell me like, what this thing is actually going to cost. well, let me, let me introduce you to this other guy. And you know, you have, have to go through all these trainings and da da da da da da. Right. It's like, there's, there's a, there's a limit. And there's a, there's a third path, which is all right. ⁓ I can just sign up. I can experience this application. I can decide for myself whether it's actually going to be worthwhile ⁓ and. and decide how I'm going to implement this if we're not. I'll ask for help if I want to ask for help. ⁓ I find it infuriating ⁓ when ⁓ software organizations, and I get why they do it, but it's infuriating that I don't have some self-navigated journey to at least get me to a point where I can make an informed decision as to whether I want to even talk to someone about this thing.

I mean, it's the classic enterprise sales process. And like, we have places like Oracle to blame for that, who have incredible sales teams. ⁓ Like, I still don't know why people buy Oracle. ⁓ To this day, like, we have such good solutions that I can't fathom, ⁓ with ⁓ the exception of a select few, like, why does Oracle still exist? ⁓ But they do. And if you ever try to cancel an Oracle product, you will discover just how good and fierce their sales team is because they will figure out some way to, you know, schmooze and figure and get you to keep purchasing their product because that's what they've invested the majority of their capital in figuring out is like how to solve the sales problem. And I hate that, right? Like I just want to buy a product because I enjoy using the product and because it solves my problem, ⁓ not because the sales guy talked me into it and made a bunch of promises. And we have, over the years, been sold plenty of bills of goods and had clients have the same thing happen. We've had to sit with clients interviewing ⁓ enterprise solutions and have them discuss all the things that are on their roadmap that are totally deploying next quarter. And I can think about one in particular that were about seven years removed from a feature being deployed next quarter. and it's still nowhere to be found. ⁓ So, that's just one of those things that ⁓ I think in that enterprise software world ⁓ is very, very common and just kind of acceptable. Whereas when getting access to your product starts with logging into the product and using it, ⁓ it's pretty clear, pretty fast if the product's gonna work or not. And especially if you're someone like us who's more technical, we've done this before, I've used every project management software under the sun. So if I'm vetting project management software for a client or for a specific need of ours, I know my way around them. I don't need your help setting it up. And in fact, I don't want it because you're just gonna be in my way.

And ⁓ when we deployed the ERP side of ⁓ the project management system that handles all of our accounting, ⁓ billable hours, and that kind of stuff, we experienced that same thing. They have their process, and they were going to take us through onboarding. And between our first meeting and our second meeting, we had already done everything. We did all the onboarding. And then they turned around and wanted to try to charge us. to train us ⁓ on how to use the reporting engine, ⁓ which is insane to me, right? Like, we just refuse to do it, but ⁓ they had mandatory training in order to use the reporting module because ⁓ somehow, someway, it's hard to create charts and graphs.

And if I remember right, that same organization, we were teaching them things about how the reporting software was actually ⁓ used and like what. ⁓

Yeah, because all they're doing is integrating good data. So they act like ⁓ it's a solution of theirs and that they've got some secret stuff that you totally need to learn from them. And it's just good data. ⁓

So I have sort of a buyer beware take as it relates to buying software of any kind. Again, first question is, do I believe this thing is gonna solve 80 % of my problems? If yes, please proceed. The second thing though is buyer beware. When you get into a place where you're having conversations with the sales reps, 100 % of the time, not some of the time, 100 % of the time, they will over promise what the capabilities are of the actual product. Once you actually start getting into the nitty gritty of what this thing is supposed to be doing. ⁓ And it's not because they're being liars by and large, it's because they obviously don't know in a lot of cases. And so they're like, yeah, I think we, I think it can do that because they have some use case in the back of their mind of how, about how it might've worked in the past. Turns out usually that's not accurate. And you get to a place where you end up having what I call desk ornaments ⁓ in the software world. You have stuff that you bought, you're on a 12 month agreement or 36 month agreement, whatever it is in the software world, and you can't use the product. It's not actually useful for what you're doing. We've had many, clients in the martech space in particular that have been like, well, I bought this database thing for my, ⁓ my B2B organizations outreach stuff. And I bought this CRM and I bought this first party data set and I bought this and I bought this. And before you know it, they have 10 or 12 different solution sets that are without talking to us ⁓ that are supposed to be helping their marketing be better. And what they really have is a bunch of stuff that doesn't talk to each other. They didn't account for the fact that they have to have people inside the business to be able to manage all of this software. It doesn't just do it itself. ⁓ And that, that The solutions that they thought they were going to be getting for these things is actually only maybe 50%, not 80, of what would solve their needs. And so there's this buyer beware, make sure you go through the assessment, find a good partner to go through that process with you. If that's something that would be helpful to you, regardless of your space, you know, we've worked with a lot of MarTech stuff, but if you're into accounting things, that's something we don't know anything about. Find a partner who knows something about accounting software, accounting solutions.

I can tell you it's worked for us, that's about it. ⁓ I think the other side of the buyer beware, right? Like if you're buying software, ⁓ if you're buying software, only buy what exists today. Don't buy it on the basis of what it's going to have, right? I've seen that a lot with ⁓ a lot of enterprise software.

Yeah.

where there's always the promise of what's shipping next quarter and what have you. And maybe a fair, ⁓ like a very few rare cases, ⁓ I would consider that. But more often than not, those things don't come to pass. ⁓ It's not even necessarily because they ⁓ just made it up and they're relying to you, right? We have seen it even with our own products where our intent is next month to deploy XYZ thing. But then the needs of the business shift and the priorities shift and that thing gets deprioritized ⁓ and we focus on something else. And that happens in every business. So unless there's a super regimented or somehow it's in your contract that they're gonna deliver that thing. I would just focus on purchasing, like, what does this solve today? It doesn't solve our problems today. Because if it is contingent upon some other feature that doesn't exist today, that feature may never exist.

Yeah. And I think, I think the, the, going back to the buyer be aware piece, it kind of encapsulates a lot of these things by saying that vaporware is a real thing. That's a, that's a phrase where you're, you're basically saying my software will do this. You, you've seen it a lot. We've seen it a lot in anything that claims to be AI powered or machine learning powered. for the last 10 years, ⁓ up until maybe the last three, when AI has actually become pretty prolific and actually really powerful. Anything that said the phrase AI or machine learning was just like, ⁓ really doubt it. It's, it's not ⁓ the, the, technology is not there. So you can use that as a marketing phrase, but it's really not there. And we have different versions of that even now with AI, ⁓ being much more useful and much more prolific in terms of, of being ⁓ a relevant tool. ⁓ that people can use as part of software. ⁓ But still, look at it, look under the hood, don't take a salesperson's advice for it, and make sure that you're getting 80 % of what you think you need out of it before you pull the trigger.

And I think that inherently kind of on the other side of this coin really sort ⁓ of highlights why you might ever want to build something. ⁓ The advantage and why we've built so many internal solutions that we have over the years ⁓ and helped clients build solutions ⁓ for their ⁓ organizations is because when you build it, you control the roadmap. which has as many pros as cons, but what it does mean is that you can ship whatever that feature is. So if there is, if an invoice approval process is super critical to you, you can ship it. You don't have to convince a product manager at some other company that has a boss to report to that has to ultimately make shareholders happy. You can just fucking do it because we make that decision. And I think in those cases, right, when you have those like super critical elements, that's when you should build it. And perhaps it can be a combination, right? Maybe you buy a piece of product that does 80 % of it. The first thing that I look at when I look for any product that I want to buy now is A, is it open source or source available? Number one, even if it's not a deal breaker. Secondarily, does it have an API? And third, is the API good? Because there's plenty of people with an API that, you it's like you can... ⁓ You can read objects, you can't actually do anything. Cool. But if it has an API and the API is good, you can augment it with the things that you wanted to do. Then you escape having to maintain and inherit all the monkeys of the platform of what does exist and does exist well. but still get the other benefits that you want because you can build the connector piece ⁓ that pulls data out or pushes data in or syncs data to and from ⁓ between those different platforms.

Yeah, I think that's a good point. think, ⁓ so if I had to create like a miniature checklist of things that I would look for in the build versus buy equation, it's, ⁓ you're right. Is it open source? Does it have an API? Is the API good? Does it solve for 80 % of my problems with the off the shelf solution? Do I think I can fill the rest of that 20 % gap by building a little thing on the side of it? because the API has availability for me to push and pull from. And if those things are true, then I can buy and build alongside it. If those things are not true, then either keep looking for a solution that does check all those boxes, or you may be left in a place like we have been in many cases where I have to just build the whole thing. There is nothing that exists to solve this entire problem, which is what Nebula is now becoming.

Yeah. Well, I think the other challenge that we have too is we also have, ⁓ we talked about it in the beginning, but it ⁓ is true. Like our barometer is maybe a little bit skewed, maybe a lot of it's skewed ⁓ for the same reasons that ⁓ my barometer is for other things, right? So ⁓ when we look at something that... ⁓ The bar to jump over to build something is pretty low, right? Between ⁓ the fact that we have developers on staff, we have knowledge of running technical products, we have designers and UX people and all of those things in-house, on staff, ready to rock and roll, we can use them ⁓ to execute those products. And not only that, they know how to do that. ⁓ Pair that with ⁓ really great frameworks that make it possible to build software really, really quickly, like Ruby on Rails. and then pair that with some of the new AI ML stuff that exists. And you have a recipe that makes it really possible to concept and build something ⁓ or even build something ready for production ⁓ really, really, really quickly. ⁓ And I sort of think about it ⁓ like I told you before. ⁓ In some ways, it's like me when I look at something like Geek Squad. ⁓ Geek Squad makes a ton of money for Best Buy. It's existed for a long time. And I can't figure it out for the life of me. Why people, ⁓ when your computer breaks, why do you take it to somebody to fix it? Why don't you just fix it? And that's because I've been working on computers for, you know, since I was 10. ⁓ And I've been fixing those things and tearing them apart and learning about them. So to me, it's like super easy to just fix your own fucking computer. And to other people, it is terrifying. The idea that you could ever ⁓ push a button or open a laptop up is terrifying. ⁓ I haven't done that shit for 20, ⁓ almost 20 years now, ⁓ or literally 20 years. ⁓ So I think that is also probably a bit skewed in the same way as like, ⁓ I look at like, need a bookshelf. And my solution is I'm going to go purchase a bookshelf. There are probably plenty of people in the world.

who can't figure out why wouldn't you build my own fucking bookshelf. And you know, so I think that is something that we also have to weigh. It's like, your organization was given resources to build things, you're

you're willing.

I need that. It is not the case that you can just build something and deploy it and never test it again. You will have to have a maintenance contract with somebody to maintain that thing. Even if it's tiny, you're going to have to do something with it. And that's something I think you need to account for as you're doing the kind of build versus buy, value, or place of hand aspect of things. You can't just price the initial project. You've got to ⁓ the whole maintenance contract as well.

Yep, definitely not a one-time expense. There's maintenance, new feature costs over time, hosting, ⁓ all the different things that take something that ⁓ costs X and now it's X plus at least 20, 30, 40, 50 % over some period of time. And that's with a minimum amount of ⁓ maintenance and such ⁓ that you would do over time. Any concluding thoughts? ⁓

⁓

I mean, think it's important to look at your own organization and understand kind of your appetite for building anything and to be realistic with it. ⁓ I think that's what we keep coming back to is ⁓ it's ⁓ more often than not, it's cheaper to buy something even if it's not the perfect solution, but it's certainly fun to build things. and ⁓ you can build some really cool stuff and maybe have something that's commercially viable and can turn into a profit center for the organization. ⁓ on that build side, it's making sure that you're aware of ⁓ scope creep is a real thing. Scope creep is a ⁓ very real thing when it's internal and it feels like it's free. ⁓ And also there's no such thing as free software. ⁓ You can build it for quote unquote free. Let's say you have resources, have anything to do. ⁓ and they can build it, that's great, but you still have to maintain it, you still have to update it. ⁓ So just bearing all of that in mind and making sure that you're evaluating the full scope of the universe when you're ⁓ doing that build versus buy equation I think is important. if you've got the resources, you've got the appetite, you have the curiosity, build something.

Yeah, I think my concluding thought would be piggybacking on something that you said. Concluding thought would be your organization has a certain amount of politics associated with it. You have it groups, you have marketing groups, you have sales groups, and all of them want something different, need something different. And you probably, if you're in our space anyway, you're to be interacting with all three of them in some way, or form as part of this build or buy process to try to solve some sort of problem. And so figuring out what each of those groups need and want, and then identifying a path to get there is not always straightforward. ⁓ And ⁓ it's difficult to weigh as part of that journey. ⁓ whether building versus buying is even a possibility. Oftentimes you probably veer towards the path of I have to buy something because it's the only way that I'm going to get commercial liability ⁓ or the stamp of approval from all these different constituent groups. ⁓ Again, going back to that idea of that may be true, but does it solve 80 % of your problem? And if that's yes, cool. Can I then say, right, will these smaller pieces that satisfy the needs of marketing, or that satisfy the needs of sales, or that satisfy the needs of accounting, or whatever else, can we build solutions to account for their needs on top of this bigger solution set that we're going to purchase that is commercially viable off the shelf solution, quote unquote? So weigh that as part of your decision making, and make sure that you're going down a path that is realistic for your organization. All right, that's a wrap.

like it.