Better, faster, cheaper. Pick... none?
I don't want to write an article about why you should buy my company's software -- or anyone else's, for that matter. Nor would I ever discount the quality or capability of open source and community-authored software. I use many such programs every day of the week, and they usually rival or top their commercial counterparts. But of the three companies I encountered who were contemplating the make-versus-buy, none are software companies, and two aren't even tech companies of any kind. One has a significant amount of digital signage experience. Another has a more modest track record in the industry. And one is still cutting its teeth on a prototype network. In all three cases, WireSpring's kit is being considered alongside a number of our competitors -- mostly good ones, with a few lackeys thrown in. (Even with over 330 companies in our competitor database, we come across one or two new guys each month.) In each case, cost is being cited as the chief factor in prompting the make-buy decision. In general, the cost-related arguments fall into two categories:
Image credit: Andrew Michaels
Software companies are businesses, so yes, we do make a point of trying to sell our products to others for money. And while some firms seem adept at gouging customers with sky-high prices, most of us either start out honest, or else we're kept honest by our competitors. Still, there's apparently a notion out there that software development involves no capital expense and has no ongoing support costs. The reality (from my point of view, at least) is that good software developers are expensive. I hate to objectify them like that, because they can be pretty awesome people, too. But awesomeness doesn't show up on my P&L statements. Salaries do. For the cost of even an extremely modest, hypothetical development team -- perhaps 2-3 developers and a QA engineer -- you can buy a lot of software. And that doesn't even figure in tech support or take into account how long it would take said developers and QA folks to build a product that was actually usable.
Another big misconception -- and I can totally appreciate why anybody who hasn't worked at a software company would think this -- is that once you've written and released your perfect software version 1.0, you can fire your development staff, kick up your heels, and be done with it. I really, really wish that was the case. (Well, except for the firing part -- see the aforementioned note about awesomeness.) But a software program is never really "finished," and even great software demands a considerable amount of expensive, ongoing maintenance. What drives this need for maintenance? Here are a few of the gremlins that are bound to pop up:
- Discontinued hardware: The playback hardware you install at your sites (whether it's a PC or an embedded device) will eventually be discontinued and replaced with a new model, forcing you to update the operating system, integrate new drivers and re-test hundreds of scenarios before you can deploy on the new hardware.
- Security patches: Mandatory security patches for the underlying operating system (whether it's Windows, Mac OS or Linux) or the other programs you use on there will interfere with your existing playback tools, forcing you to re-write those tools to be compatible. Internet Explorer has been notorious for this, with even a small change in the IE security model requiring major changes to digital signage playback tools that rely on IE for showing any type of web-based content.
- New content formats: Your customers will eventually want to display new content formats that didn't exist when you first wrote your playback software, requiring you to integrate new codecs or upgrade the existing ones.
- Bug fixes: No matter how much you test before releasing a software product, some number of bugs will crop up once it's in the field -- and it can sometimes take years before a given bug shows up. Like it or not, you'll probably be issuing bug fixes for the life of your product.
Fallacy #2: We have elaborate, complex and unique requirements that need to be designed from scratch
If you really, really wanted a teal and fuchsia zebra-striped car, would you buy a car and get a custom paint job, or would you get an engineering degree and redesign the internal combustion engine? I have a slightly more diplomatic way of phrasing this when talking to potential customers. But what it boils down to is that when taking a from-scratch DIY software approach, you will be spending time and money solving problems that others have solved already. And I can tell you from experience that even seemingly simple tasks -- like reliably moving a file from server A to player B, or getting said file to play smoothly from beginning to end unattended -- turn out to be pretty complicated when they have to work in the real world, and not just in your development lab.
At the same time, I understand that all businesses have unique requirements, and some might have enough complexity to warrant writing software to automate (or at least improve) those processes. But in my book, that just calls for a good API and some engineering cleverness. I can't think of many real-world cases that would warrant a rewrite of what is basically the digital signage industry's equivalent of the wheel.
Perhaps you've done the math and considered salary expenses, time-to-market delays and opportunity costs, and you still think DIY software is a good idea. In that case, you're either planning an extremely huge network with remarkably unique needs, or you're underestimating some part of the DIY proposition. That sounds like a harsh conclusion drawn by a biased party, and maybe it is. But given how many do-it-yourselfers have become our clients and the clients of our competitors over the years, I've noticed a clear trend that goes like this: (1) Meet new prospect doing make-buy analysis. (2) Prospect chooses "make." (3) Wait 2-3 years. (4) Get new call from old prospect looking to retrofit old network. (5) Repeat. This cycle is costly for everyone and ultimately limits the growth of our industry, as otherwise promising network owners spend their time re-inventing the wheel, instead of expanding their networks and creating compelling content that achieves real business goals. Hopefully this article will help some of those people ask the right questions and understand the true costs of writing their own digital signage software, and enable them to make the best technology decision for their business. And if not... Well... I'll see you at step (4) then!
RSS feed for comments to this post