How much are you willing to pay to make your life easier? What’s an hour of your time worth?
We’re pretty DIY-y folks at my house. I like to sew. I love gardening. I make pizza. At some point in the distant past, I reveled in the “purity” of doing everything by hand—raking the leaves, kneading the dough, embroidering with a needle and thread. But that gets slow. Like, really slow. And boring. And boring + slow = quality slippage. Hand-embroidery is nice, but sorry; I didn’t have the energy to measure it properly, so it doesn’t fit. If I’m spending two hours raking my yard, I’m not spending much time planting bulbs for next spring. And the pizza? Forget about it. Order in. So I invested in a sewing machine, a new mixer, and a leaf blower. I’m learning how to make dresses, we’re having fresh pizza once a week, and our daffodils look lovely, thanks. Point being: good tools save time and raise the bar on quality. But still, sometimes buying isn’t the answer. Sometimes building the feature—or finding a free version out there—does just fine. Here are my thoughts on when to build and when to buy.
If your development team is in a location with a low cost of living—drastically bringing down your overhead—then sure, build it yourself. Just make sure it’s reusable, well-tested and well-built. And don’t forget to calculate the cost of communication. A twelve-hour time difference is an expensive opportunity cost.
There’s an adage in the construction industry: “Fast, cheap, or good: pick two.” Meaning: if you want it to be cheap and good, don’t expect to get it any time soon; if you want it to be fast and good, expect to spend a lot of money. I used to build internal corporate applications, and our adage was “Fast or good: pick one.” Money didn’t enter into the equation because we were all overhead, and our cost was measured in time only. When our internal clients wanted top-quality, we took our time. When they wanted it fast, we hacked it out. And we built basic features from scratch. Was it the best solution? Not really. But we did it anyway.
If you’re 100% sure that you’ll never, ever have to come back to this application and fix it, upgrade it to new browser requirements, or otherwise deal with it ever again, you don’t need the support of a licensed control set. (Of course, if your client comes back to you a year from now and says, “That was great! Let’s do it again!” that’s a different story.)
If you’re the developer, the designer, the QA, and everything in between, I strongly recommend buying a licensed toolkit from a respected company. Yes, it’s added annual cost. But for that price you get an extended support team, a community of users, and, in the case of ComponentOne Studio, frequent updates that resolve inevitable issues like browser and software compatibility.
See above point re: browser compatibility. My previous team spent weeks troubleshooting an issue in a rich text box because it threw a rod when tested in IE11. The developer had found the free control two years earlier, and once we found the error, he spent two months sending emails, support tickets and phone calls to the company and got nothing in return. At long last, they sent us a fix—but not until after our rollout of IE11 had been delayed for six weeks.
If your work consistently requires a fast turnaround on deliverable software, go for the buy. The beauty of dragging and dropping a completed, reusable control into a page cannot be overstated. You don’t want to spend hours tinkering with resizing a column in a grid when someone has already done it (and dozens of other mundane tasks) for you. You can spend your additional hours thinking about the actual creative problems you’ve been hired to solve.
For more information on calculating the monetary value of buying a control set, see A Simple ROI Calculator: Kicking Off the Software Build vs. Buy Conversation. Or check out the full library of ComponentOne Studio controls.