RR 382: "When to Build... When to Buy" with The Panelists

Episode 389 · October 2nd, 2018 · 1 hr 3 mins

About this Episode


In this episode of Ruby Rogues, the panel talks amongst themselves the topic: “When to Build, or When to Buy.” They discuss how time is limited, and whether it is worth their time to build their own app/software or to just purchase. They discuss the pros and cons of each. Check-out today’s episode for more details!

Show Topics:

1:40 – Chuck: Anything that prompted choosing this topic?

2:13 – Dave: I am not a huge stickler of keeping tracks of things. With a new car, I wanted to start this off right. I wanted an app to show history of car. I wanted a simple view and wanted to take pictures of receipts. I didn’t find anything out there that I liked. Do I want to write a web application?

3:29 – Dave: I am going to write this app. There is a lot of the new technology, so I can keep up-to-date with real world technologies, with the act of storage. Keeping my skills sharp. Solving a real world need that I have.

4:06 – Panelist: Funny thing. That is a decision that has evolved with me. As a younger developer I would build everything that I could. I thought: “I have to own this,” I thought I have to have total control of this. This is for me. I try to buy everything that I can. There is only so much time in the day. Let’s point the question back to Dave. Are you more in the process of creation?

5:19: Dave: It fits to my needs. I don’t need something overly complicated. I think we often find situations where there is a justifiable case to build it then to buy it. If you buy it you have little control over the features and other things. What’s important to you is not important to others. So you will have to find a company that will meet your needs.

You bring up an interesting topic and that’s data.

7:29 – Chuck: You are talking about the level of control. Eric this might sound familiar with sponsorship and so on. Eric said: Dude you are a developer. There is nothing out there that I need so I have to build it. I opt to trying to buy it if I can.

8:35 – Panelist: Yes, definitely.

By focusing all of my attention on an application that won’t give me an ROI. Leave that other stuff to much smarter than me in that domain.

9:24: Panelist: I agree. If it is a core part of your business than, if you are buying, that might be a disadvantage. For example...

I used a service called IMPROVLY.

12:00 – Chuck: it might not give you the control that you want, but if it can get you most of the way there then it will eventually move up in priority.

12:33 – Panelist: Look at utilities that support you, then that’s where MVPs can come into play. One limited, viable product. For example, the app tracker for my cars. I just wanted something simple. Some of the extra bells and whistles can come later.

Something like code fund – there is a lot of expected features. There is so much business that goes into it.

When I have time to build that stuff in then I will do that later. If it is too feature-rich then they will overwhelm themselves. They try to do everything today. Often that could lead to bad code, things not working properly. You save time by doing it right the first time. I think you have to really gauge what is your MVP? What can I do to make this functional? Then add in the features within the application.

15:19 – Panelist: When you decide to build – how much influence past products to drive your development.

15:38 – I say a ton, because then you are going to be reinventing the wheel. You OWN interpretation to things is fine. There is only so many ways to build something. See what people want and what they need.

16:15 – Panelist: It tends to muddy the developing waters a bit. I like to approach things not knowing what the competitors are doing. Then you aren’t constrained by past examples.

I approach it as: How would I want to approach this by an individual so I am not blurred by competitors. 

18:05 – Chuck: I build a feature I need and then ask myself: How do I put this together?

What I need – I know what the outcomes need to be. At the end of the day I am looking for a model to provide what I need. In both of those cases.

18:44 – Panelist: Yes, having a good knowledge of the domain is good.

It is more fun to build, right?

19:37 – Is it fun to build or is it to integrate? I like integrations better.

20:13 – Chuck: I have recently been integrating ZAPIER.

21:12 – Panelist: There are some things I will stay away from. I want to keep things with the specialists. If that means I am paying for the fees to use a third-party.

21:56 – Yes, 100%. You have to ask yourself: How lazy are you with X?

23:08 – If Twitter goes down then what? Have multiple options. You need to have other ways to authenticate in that area. So that means you have to be developing in...

I think that will come down to your business needs. It will help the workflow, and help you make decisions If you are pinning yourself into a corner on time and resources. I think it’s sad that that has to be said. But look at other applications out there that are pinned into corners. People didn’t think of what they would need in the future. I am not saying that my products aren’t exempt form that.

25:52 – How do you qualify a good buy? This hits my criteria for the buy.

26:06 – If it’s providing a value. Not just this month but the following month – is this going to be worth the value. Mail hosting. This is worth it to me. There is so much hassle that goes into it. Then I have to maintain it. My business is hurting because I am focused somewhere else. I want to be able to answer emails from people. Focusing on the products that I am providing. Do I need to pay someone to support

27:35 – Panelist: The speed to integration and the speed to usage. It’s all about the pain. How much pain will there be to build one? Hire the laziest person possible. I pride myself being an extra lazy developer. I can I build the best thing in the least amount of time. Time with my brother in the past has shown me this. Perhaps the type of developer we are determines the answer to that question. I like to get code out the door more than create the code. What about you guys?

28:56 – Chuck: I like building it but I LOVE shipping it.

29:07 – I like creating it. Shipping part is the “I finished it.” Getting from nothing to something. Shipping is like the celebration for me.

29:32 – Digital Ocean Advertisement. 

30:10 – It’s not to say that I don’t buy things, cause I do. The amount of software that I buy outweighs the ones I build. My time is limited. I do need control over the data. We were struggling a few years ago financially. I need a thumb drive and we fought on whether or not we could buy that. Finances are intimate details. If that information was stolen, so I built my own we application in my business to hold our finance data records. We wanted complete control over that. I saw that that it was a wise investment of my time. I had insecurities about that information leaked or stolen. Now we have too many thumb drives.

32:31 – I bought a thumb drive years ago for it and paid $50-60 for that. Which is insane.

32:55- Chuck: Build vs. Buy topic has been covered very well, so far.

When you are building, which features to prioritize? Building features – which one to prioritize?

33:47 – It would be less impactful to your client base. You have sponsors and signing up for the show. The listeners could be returning guests. But your sponsors are coming on ALL the time. Feature rich platform for them. You want them to enjoy using your product. I think that would be the most important. Having something for your scheduling. It doesn’t have to be feature rich. But

34:43 – Chuck: I understand the trade-offs. Anything I can do to make the system automatic then that helps. Some people want some LIVE episodes.

That leads the sponsorship into the content production stuff. Beyond telling Eric, my editor, where to put the ads within the episode.

36:52 – Panelist chimes in.

37:15 – They want the testimonial. The other end to that when we started off we got sponsors because we were novel. We were a different take on Ruby. The market has changed. Things change. Then it was okay well Ruby Rogues was a great way to meet developers. You can do conferences but you reach a lot of people in one week. Some of our sponsors early on - they past their ROI. Podcast market has changed. Some of this feedback has made me rethink things. The market has changed. People want to hear the personal touch and the personal message. They want to hear how these things are being run and how to fix the bugs. Just being aware of the needs and how the needs change. It is easy to get comfortable. Then it turns out jQuery doesn’t always cut the mustard anymore. But maybe it does? If you get comfortable then you will pay for it.

39:58 – So true. Like Code Fund.

Blog Post: What is Keeping Me Up At Night?

41:11 – Chuck: Even their needs have changed. That feedback is crucial. It’s not just about keeping tabs on this stuff. Why are you loosing the publisher? Are you getting the feedback that you need. I am have gotten critiques from Eric and other people. Oh ok, let me change the packing to serve their needs. Kind of roll with the punches.

If you aren’t talking back to your customers then there will be issues.

42:18 – Panelist: Side topic of how do you receive feedback? Some people there is a small minority that will bash you. They won’t give you constructive feedback. They are being a mean person.

Having a good attitude is going to help with the feedback to make your product better.

43:15 – Chuck: Nobody wants to have that confrontation.

43:30 – I have grown to appreciate humanity. When you are asking them about: why did you leave?

I see that they’ve read it 4-5 times but they didn’t hit reply.

Am I doing this? Am I not doing this?

45:11 – Getting the opinions out there can help you if you can find the positive twist to even negative comments.

45:44 – How can this feedback make me a better person, podcaster or better in general? You can find that in the nastiest feedback that you may receive.   

46:29 – But on the flipside – if you decide to buy – make the feedback constructive. Honestly

46:56 – I had a similar experience. Geekbot. I just bought it and I love it. They do daily standups on Geekbot. They kept skipping days. But they asked for me to try again, I di and I am glad that I did!

48:49 – Panelist: When you are talking about building your own software and you get that feedback it’s important not to be a person pleaser. If it doesn’t help ALL then it’s something you might NOT wan to build it. I t has to be globally beneficial. Do the right thing. I

50:49 – Chuck: Anything else?

51:01 – To UNSUBSCRIBE make them fill out a long form before you leave. One more kick to the groin.

51:17 – Chuck: Subject Line: Please Piss Me Off.

How can we make this more effective?

51:40 – I send them weekly stats. I solicit through that e-mail.

52:00 – I think the point is that most people who buy software are HEARD and that they are a valuable customer. Their voice does matter. You want to solve their problems in a least expensive way.

52:36 – Chuck: Making it SUPER easy for them.

53:18 – Final thought about building: if someone has to leave your application, to do the task at hand, then your app is missing some core feature(s) that your users are wanting.

54:27 – Picks!

54:32 – Advertisement for Get a Coder Job!