Panel:


Charles Max Wood
Dave Kimura
Eric Berry


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?