Show Notes
In this episode of Startups For The Rest Of Us, Rob and Mike answer the question of whether to build or buy. Just because as a developer you know you can build it doesn’t mean that’s the best option. The guys do a gap analysis on building versus buying software.
Items mentioned in this episode:
Transcript
Mike: In this episode of Startups For The Rest Of Us, Rob and I are going to be talking about how to answer the question of whether to build or to buy. This is Startups For The Rest Of Us Episode 355. Welcome to Startups For the Rest of Us, the podcast that helps developers, designers, and entrepreneurs be awesome at building, launching, and growing software products, whether you’ve built your first product or you’re just thinking about it. I’m Mike.
Rob: And I’m Rob.
Mike: We’re here to share experiences to help you avoid the same mistakes we’ve made. What’s going on this week, Rob?
Rob: Things are pretty good. Feels like a summer is turning into fall and I’m ready for another summer before winter starts.
Mike: Is it like the post-vacation vacation?
Rob: A little bit like that, yeah. We actually got a pretty cool email from [Tom Lagris 00:00:48] and the subject is How To Survive With Health Coverage In A Startup. He says, “Love the show, listen to every episode on my commute.” He lives in Melbourne, Australia. He said he wanted to comment on our discussion from Episode 352 around health care, and I’ll read from his email.
He says, “An option which people do is to move abroad to start their startup. Obviously, this depends on family situation, if you need local networks of people for discovery, etc. But a SaaS business can be started from anywhere, and in fact, many countries actually offer funding to entrepreneurs to go their first six months to build stuff. For example, [00:01:19]. If you pick a country with free or baseline healthcare like the UK, Australia, or New Zealand, then you have solved the healthcare problem. Using Stripe Atlas or similar still allows you to have a Delaware/US entity. That would be an idea for future episodes, best countries to go for six months to a year to build your SaaS product. Cheers.”
Good advice. I think if I was 20 years younger I would totally consider doing that.
Mike: Yeah, that reminds me of Tropical MBA episode I heard a while back, Episode 365, where they talked about Estonian e-residency and all the different things that go into it. Just reminds me of that and the idea of being location independent because that’s really what the Tropical MBA is based on. It was really interesting hearing from the Director of Estonia’s e-residency program and how they’ve positioned it to allow people to establish that e-residency and then work from anywhere in the world and just basically use that as their financial center.
If you’re interested in that, we’ll link that up in the show notes but I’ve definitely recommended that for people. If you’re interested in looking into going abroad and getting an idea of what one country’s solution to that particular problem is, there’s a lot of different places that are starting to offer very similar things.
Rob: Yeah, I certainly think it’s not for everyone. I think that depends on your personality and that depends on if that type of thing is interesting.
When I was younger—I enjoy travel now more than I used to. Frankly, when I was in my 20s, which is when I probably would’ve done this, before I got married or before I had kids, I kinda wanted to be here to start the company. I think it depends on really what your goals are and your personality and that kind of stuff.
How about you, what’s going on?
Mike: We got another email from Steven Johnson who said, “Hi Rob and Mike, I wanted to say thank you. I love the community and the podcast. A year ago, I was doing around $5,000 a month and I started listening to your podcast, made some change to my business based on what I heard. Since April, I’ve been averaging about $15,000 a month.” Steven writes us from Glacier Peaks Studios. That’s great to hear, Steven. Really appreciate that email.
Rob: Yeah, that’s awesome. This is one of the big reasons, when we get emails like this, this is why we do the show and this is why we do the conference and this is why we talk about this stuff and share the knowledge we’ve learned. It’s to help other people, to build the community and have us all have the rising tide lift all the boats.
Mike: Aside from that, the other thing I’ve got going on is just banging away at support issues and getting customers on-boarded into Bluetick. My launch went reasonably well for what my expectations were, and things are moving forward at a fairly fast pace at the moment, just making changes to the app and making it easier for people to self on-board and guide them through the on-boarding process, identifying where the bottlenecks are and hopefully get them solved.
Rob: Doing support and on-boarding, do you have any time to write code?
Mike: For the on-boarding, it’s a lot of code that’s in the app to recognize certain conditions. When those things come up, that’s most of the code I’m working on, just making it so that it can identify what the next steps are for the person, and then say hey, this is what you need to do to make things easier to find in the app. For example, if a mailbox starts to fail, or if they haven’t even set one up, pop up a message when they first log in. It says hey, this is what you need to do, so that they know exactly what they need to do and they don’t have to go to a personalized on-boarding session or anything like that.
Rob: Yeah, that makes a lot of sense. The nice part is as you do this, you should receive fewer questions, you should see more people getting further into the app. We used to have a dashboard where we had three or four steps that people needed to do to get set up with Drip. Next to each account we had, it was like checkboxes. I could just flip to see all new trials and I could see who hadn’t checked the boxes. We started basically measuring progress on an aggregate basis of what percentage of current trials have installed the Javascript, have activated a campaign, have activated a form or whatever. I forgot what the four steps were, I think another one was a workflow.
We definitely saw noticeable progress to a point, and then it just stopped improving. You peak out, that’s when it told us we’ve done a pretty good job with our on-boarding, it could probably be improved but we kept adding stuff in it and it wasn’t really doing it. Hopefully, you will get to that point soon. Then, you can stop. You can stop worrying about it for now and get back to building features and doing whatever else it is that you need to do.
Mike: Yeah, that was one of the first things I did, built a dashboard. It has almost, kind of what you just described. I used numbers to indicate whether or not they’ve done it or not, then it’s just color coded at the boxes in a basic table. Anyone who’s logged in or who’s creating an account or subscription, I could see whether they’ve done this step. For example, they added a mailbox, yes or no. It’s color coded if they have; it’s red if they haven’t, and it’s green if they have. Then it tells me the number that they’ve created.
I can see how far they are along and how heavy of a user they are as well, but I don’t have anything that gives me statistics or overtime what the percentage or conversion rate or anything like that is on those. That’s something I probably have to add in at some point. Yeah, that’s the basic stuff that I’ve been doing right now.
Rob: Sounds good. What are we talking about today?
Mike: Today, we’re going to be answering a question that came from [Christopher Yarl 00:06:29]. He had a question about whether to buy something off the shelf or to build it.
He says, “Hi Mike and Rob, thanks for the great podcast. I’m currently planning my next step for my business which is a small SaaS app. My question is this, one of the components that I need is a JavaScript library with some specific drag and drop capabilities on the frontend. There’s one commercial alternative out there but it’s pretty expensive and buying it would consume a lot of my available resources. I’m also hesitant because chances are that only supports about 50% of the functionality that I need, which will leave me with very little funds. I’ll still have to do extensive programming on my own in a library that I’m not familiar with. What would you do in a case like this and why?”
I thought what we’d do today is walk through the general steps that you would go through and the questions that you would ask if you’re in a situation like this where you’re trying to figure out whether or not you should buy this library even if it’s very expensive, because I’ve been in situations before where I have this library or this piece of functionality that I want or need, and the library for it is expensive. It could be a couple thousand dollars, and it might not get you as far as you want or need to be.
The fact of the matter is you’re going to have to learn all the stuff that goes with it, and it may not be worth it. The question is do you dump a couple thousand dollars on something, or even if it’s a couple hundred if your budget is much smaller, do you do that and then try and figure out afterwards or there are other ways around this particular type of problem?
One of the dangers that we have as developers is that we know that we can build almost anything given enough time. The fundamental question here is how do you determine when it’s better to build something versus buy it? It applies to things like software libraries, components, infrastructure, entire software packages for example. You really need to do some sort of a gap analysis between whether or not you build versus buy. But in order to do that, you have to have questions that you’re going to ask to help establish what that gap looks like.
Rob: Yeah, I do think there are times. I think in most instances, if you’re thinking about build versus buy, hopefully you’ve already thought through this seriously. You’ve already thought, “Do we actually need to get this going?” You spent time evaluating it.
But I do think it is an interesting thought experiment to sit down and think are there alternatives to this, to doing it the way that you want right from the start. I think about in Drip, we have workflows which are visual marketing funnels. We didn’t build those from the start, we built basic automation rules to start with which were basically there’s a trigger on the left, there’s an action on the right, there’s dropdown lists to select what you want to do. We didn’t invest the five months of time or whatever many thousands of dollars. I’m sure if a library even existed to do that kind of stuff, it would’ve been expensive.
We didn’t do that because we were able to get by for I guess a year, a year and a half, with just basic automation rules. That’s something to think about, it’s not going to be in all cases, in some cases you absolutely need to get the dragon drop or to get the best thing for the job in order to make the app work. If not, it’s always good to think about alternatives.
Mike: Next step when you’re doing your gap analysis is to try and figure out what the critical features are that you need, versus the ones that are nice to have. Rob just described what the process they did with Drip was where they didn’t build those workflows, the visual workflows upfront, they just built these little rules that you could chain together and they all ran independently with much more of a manual process, I’ll say, to put them together, but it worked. That’s really what helped people in the early days and helped the business get to a point where it was making money.
If it’s not directly in the path of getting the business to making revenue, then you can probably avoid it. You can probably get away with not doing it. I think another piece that comes into answering this question is how far along are you in the business? If you’re not making any money at all, these types of questions make a lot more of a difference than when you’re making $10,000, $20,000 a month because then you’ve got money to play with, you’ve got revenue that’s coming in, and you can pay for things. Versus when you still don’t have any money and you’re not real sure whether or not that bet is going to pay off.
I think that’s the fundamental place that Christopher is coming from, he doesn’t have a lot of money to dump into this because it’s not making anything yet.
Rob: Yeah, which is a tough sell for me. In his situation specfically, given that he’s going to spend almost all his money and then still have to write a bunch of code which is only going to get him halfway there, I would either not buy it and build it, which I have a tough time saying. If there’s something that can save you months of development time, it’s almost always worth buying.
The second option is I would consider saving up longer, get more money in the bank so that it doesn’t kill all of your savings. But it’s tough. Early on in your entrepreneurial career, you’re going to have more time than money. Then later on, you should have more money than time, and you’re going to swap at some point. It sounds like Christopher is still early in his career. If you do have more time than money, you can hammer this out and you can work these long nights and weekends, or even during the day, he doesn’t mention that he has a job.
I would honestly probably, if I were in his shoes and I was thinking about this, I think the money is probably going to serve him better somewhere else. It’s a tough call but that’s probably what I would lean towards, just hammering it out, which again I hate to say because as developers we always want to build it. “Oh, I can build it better, I can build it cheaper than that person.” You’re going to way underestimate how long it’s going to take you.
Mike: But I think the third option, which is kind of an implicit one, is can you just avoid either one? Can you just not buy it and not build it at all? Can you get away without it and completely, for the time being—not to say you’ll do it forever, but can you push off or delay the decision until much further in the future? I think in a lot of cases, there are definitely ways to do that which will help you move the product much further forward than you otherwise would if you sat down and spent all the time working out through the library and building stuff.
It really depends on where that component or that library has to reside in your code base and what it does for you. But there’s a lot of situations where you don’t even have to do it at all and you can just avoid it entirely for the time being.
Rob: Sure, that makes sense. I think in the context of this episode, we should assume that, obviously, you’ve evaluated that and you’ve decided that you do need it. We should expect, if Christian was asking that question, obviously if he can avoid buying it then he should or avoid building or buying then he should. We should probably assume that he really can’t, that it’s the core of his app. Let’s just assume it’s the one feature that is going to be in his app, this drag and drop thing.
With that in mind, the next to tie in to each other, on the next things to think about, one is when do you need these features available in the timeline of your app? What would be the timeline to develop them, to build them from scratch versus to buy them. Is putting the money down, does it save you enough time that it makes it obviously worthwhile? Does it save you two months or three months and you have other competitors around, or two or three months is a vital component to your success.
I think about something like LeadPages acquiring Drip. During the acquisition process, one thing that Clay, the CEO of LeadPages, had said was this is going to give us a two-year jump in this space. They could obviously have built their own ESP, they have software developers, they have product people, they had funding to do it. But he said the reason we’re paying this money for your company is to really leap frog us. That time that it’s going to save us is a big deal for a company that’s trying to get somewhere very quickly.
If you’re listening to this podcast, the odds are pretty low that you’re in that boat. But this idea of when do you need features available and how long will it take to build them, I think, is the next thing to think about.
Mike: Next on the list is do you have the runway available to develop those features if it takes twice as long as you think it’s going to, if that’s all you work on. By all you work on, I mean nothing else gets done during that time. Can you coast until those things are done?
This really goes back to the fact that most of us are inherently terrible at estimating timelines, especially when they get too far out. It’s easy to say okay, this is going to take me a couple of hours, or even on a longer project to say three or four weeks, yeah, we can get this done. Once you get out to something that’s three to six months, there’s so much involved and all the things that need to go in it that it’s going to be really difficult for you to identify in advance all the little gotchas and edge cases that you’re going to run into that need to be dealt with.
For you to replicate a lot of things in a very complex library is going to be difficult and it’s probably going to take you twice as long as you think it will. That’s not just because we’re bad at estimating, it’s also because we’re inherently overoptimistic as developers over what sorts of problems we’re going to come into and our ability to resolve them in a timely fashion because we’re going to get pulled in a lot of different directions. It’s difficult to dedicate all of your time to just those things.
Doubling the amount of time that you think that it’s going to take is probably a reasonable, if not overly conservative thing. You might even want to quadruple it.
Rob: Yeah, I think that’s the key there. Double or quadruple. It just does wind up taking a lot of time. Often times, because we don’t think of edge cases, once you get into something you realize oh if I don’t do that, then it’s going to break, this is confusing for the user so we have to add this whole other series of screens or something like that. I agree. This is a tough one. It’s so easy to be optimistic and estimate one month or two months to build something and have it easily take four months to actually get it into production. There’s a difference between packing out some code and actually having fully unit tested, high code quality, maintainable performance, all these things can easily take you another month or two. It’s something that we don’t really think about.
Another thing to consider is can you resell what you think you could build? What you’re building, is it related to the existing product or would you need to target an entirely new audience? Obviously, if it’s a new audience, you don’t even want to think about launching a second product. It is interesting to think that if you were to build the library, would anyone else out there buy it? Again, I’m guessing the answer is going to be no, that it’s not worth it for the distraction. It’s definitely an interesting thought experiment, I think.
Mike: I think ideas like this come up a lot when we’re developing things just because we look at that and say it’s been really valuable to me, maybe I can make some money from this and sell this component to other people and build a business around that as well as this other thing. Really, you’re just splitting your focus. In most cases, it’s not going to work out, unless you’ve built out an API or a library yourself that is usable in a general case scenario and you have the time to dedicate to it. Chances are really good that you probably don’t have the time to dedicate to it because it’s a lot more time consuming to build a second business at the same time as the first. It’s honestly not going to work out very well in most cases. Can’t think of an example of where I’ve seen somebody develop two different products at the same time and sell them to different audiences.
Rob: Yeah, you’re just stretched too thin, especially when you’re a solo founder.
The next thing to think about is what commercial or open source options are available? Are they cost effective in meeting your timeline? Because buying something can be expensive. If it doesn’t get you all the way there, then there’s still that whole lot of struggle of adding onto it. And then open sourced can frequently—ah, I shouldn’t say frequently. It can be more trouble than it’s worth if you get something that is not maintained going forward, you get a project, essentially, that gets abandoned or that has already been abandoned, or maybe you get it and you spend a week tying into the API and then you realize that it’s buggy or it doesn’t do what you need to do. This part is harder than it seems. It’s relatively infrequent that I think you’ll find a perfect match off the shelf that you can buy that’s going to solve all your problems right away.
Mike: That’s totally true, but I don’t necessarily think that you need to solve all your problems right away. Really in the early days, we are just trying to solve the problems for the customers and there’s a lot of things you can get away without doing. If you can just curve off a tiny little slice of the thing that you’re trying to implement that is in the path to revenue for your customers, then you can find an alternative that isn’t nearly as good as what you want.
Yes it’s a suboptimal solution, but if you integrate it in such a way that you’re only using those pieces that you desperately need to get something working that people are going to pay for, then it gives you the ability to go back to it in the future and buy something that is more expensive or has more features and is an alternative to the one that you’re originally looking at. Maybe that’s the optimal thing that you should buy, but are there solutions out there that are a lot less expensive or can get you to where you need to be that are an alternative to what the optimal solution is for the time being?
Along with that, is the technology or the component that you’re looking at, is going to provide you with any sort of a competitive advantage? That competitive advantage can be either speed, efficiency, productivity. All three of those things can be either for you or for your customers. If you can put something into your app that is going to make your customers more productive or more efficient at what they’re doing, then they can get into your app, do their job, and get out. It will provide more value to them because of those things. They’re able to do those jobs faster than they would if they were in a different app.
Again, those things apply to you as well. If you are able to develop something faster or be more efficient about the resources you’re using, maybe it’s AWS resources or servers or backend storage, if the component allows you to do those things at a lower cost and is able to improve your bottom line because you’re not spending as much money doing hosting for example, all of those are things that you should take into account when you’re trying to determine whether or not to build or buy it.
Rob: Here’s another thing I’ll throw out. With Drip nowadays, in almost all cases, we would choose to buy it just because we’re at the point having the funding of LeadPages. It would be pretty extreme that I would want to take developer time away from building features or scaling the app to go build something. Not even build but think about an example, continuous integration.
We pay hundreds of dollars a month to Circle CI, to handle continuous integration, but there are free open sourced CI servers that we could download, put on a [Easy 2 00:20:44] instance or multiple, scale that computing power up and down, but we’d have to maintain it and that needs someone to learn how to use it and it would be a switching cost. When you look at it as a few hundred bucks a month and you think about not only how much does a developer make but how much you’re losing, the opportunity cost of a developer, a dev ops person, not improving the app, it’s a bit deal.
That’s the other thing. All of this rotates around how fast do you need to move and how fast do you want to move. And then how much money do you have?
Mike: Coupled with that, you said that you’re paying a lot of money for Circle CI. There’s also a question of what is the maintenance cost of keeping things up to date? Are there things that are going to be changing that are outside of your control, or do they handle it for you as part of the updates? That could be protocols that are changing on the internet.
If you got a networking library for example, a lot of times it makes more sense to use something off the shelf than to build your own because there’s so many different edge cases and exceptions that you can run into that you’re just simply not going to think of or consider when you’re trying to build your own. It’s just too complicated to keep up to date with all the different things that are going on.
Rob: Finally, I think the question you should probably ask anytime you’re building a future, considering spending time or money on something is can the scope of what you need be reduced in any form or fashion? Going back to the first principles and rethinking do you actually need to build or buy what it is that you’re thinking about, or is there an alternative or is there a way to reduce that scope?
Mike: Hopefully, a lot of these questions that we’ve surfaced and the topics that we’ve talked about resonate with you in a way that helps you determine whether or not you should build or buy something. Really, you just need to go through the list of things and say what is the most important thing to you right now and are there things that can be pushed off? The final thing is do you even need to make this choice right now?
Rob: That wraps us up for the day. If you have a question for us, call our voicemail number at 888-801-9690 or email us at questions@startupsfortherestofus.com. Our theme music is an excerpt from We’re Outta Control by MoOt used under Creative Commons. Subscribe to us in iTunes by searching for Startups and visit startupsfortherestofus.com for a full transcript of each episode. Thanks for listening, we’ll see you next time.
Always thrilling to hear our pod named on one of our favorite pods! 😀 Keep crackin’ guys