Should I Build or Buy? (RE: Sofware for Managing and Publishing Data)

Johnny Levy, President
Hello! DataJoe sells a software platform for companies that publish directories and other data sets. So we will not claim to be unbiased on the issue of whether a publisher should build its own software platform, or buy (license) DataJoe. Obviously, if you build your own data platform, you won’t license ours.

With that said, we want to do business with companies who can truly benefit from our solutions. We have spent 15-20 combined years in the industry solving data problems for publishers. We have consulted and we have wrestled. We have helped many publishers save time and create revenue, and helped countless publishing companies out of ridiculously messy data situations. Editorial data is the language that we speak day in and day out. So we hope it is profitable for you if we share principles we have learned governing whether a publishing company should "build or buy."

There are two ways to build:
·         In-House Developer
·         Outside Contractor

Generally speaking, you build (either in-house or using a contractor) when your data product is your entire business (i.e., if you are a data company, and data is your primary product). Why?
·         You need total control and total flexibility. You need to control the minutia of what you are presenting to your market, in order to maximize efficiency and revenue.
·         You are willing to invest. This is your core business, so it makes sense to invest the large quantity of time, energy, and money that a custom solution requires.
·         You can leverage the software cross-company. You have multiple areas in your business where you can leverage the software to your advantage. You don’t want to create a “one-trick-pony” if you can help it.

·         More time. It generally takes more time than you think it will. With custom, no one gets it right the first time. It requires multiple iterations and revisions to create a stable software platform.
·         More money. It generally costs more money than you think it will.
·         Resource drain (in-house). If you are building in-house, you’ll need to account for the drain that this will place on your development resources. Fires will arise that will force your developer to abandon custom development and fix the fire of the day. Completion will be pushed back.
·         Lost in translation (contractor). If you are using a contractor, the burden of communication lies with you. Generally, you will be dealing with a contractor who DOES excel in programming and technology, but who DOES NOT specialize in editorial data publishing. You will need to bridge the gap, taking the time and effort to communicate the intricate details of your business objectives. And here are the two pitfalls that tend to occur: a.) They misunderstand something in your instructions and implement incorrectly, or b.) you miscommunicate, forget, or miss saying something in your instructions.
o   I have been through this process multiple times. Most recently, we commissioned a Mobile App to be built for us by a contractor. Even knowing the software development business as intricately as we do, we experienced both problems mentioned above – we missed communicating important functionality that needed to be there, and the developer misunderstood some of our requests. They didn't at all think like data publishers, because they weren’t – they were app developers. Needless to say, we spent a large chunk of money, and weren’t at all satisfied with the results. This doesn’t always happen, but it’s the danger of contracting with someone outside your industry.
·         Obsolete platform. Technology is always moving. Whether you build in-house or use a contractor, the clock starts ticking upon completion. Changes and updates will need to be made in the months and years to come. Updates will require money and/or time. These updates become more major with time. I have seen this many times – a publisher ends up with an unwieldy, unsustainable platform that creates more frustration than benefit, because the publisher didn’t have the time or money to spend to make the necessary improvements.
·         Partial solution. An alternate scenario to the above is that you realize early that there are basic functionality changes/improvements that need to happen, but the wear and tear of getting the first iteration live makes you hesitant to wade back in. So your people have to learn workarounds to account for all the things your solution should do, but doesn’t.

Major principle:
Don’t start what you can’t finish. Creating a software platform from scratch will require multiple revisions, a maintenance plan over time, functionality enhancements, and technology updates in order to stay viable. It’s not like building a model train – it’s more like raising a child from infancy to maturity (I know this is a stretch, but I am just trying to account for the fact that all software starts as an idea, and then undergoes a process of growth and change over time.)

 *          *          *          *          *          *          *          *          *          *          *          *         

There are multiple ways to buy:
·         Purchase shrink-wrapped (one time fee, then pay for updates)
·         License ongoing (ongoing fees)
Because there isn’t a specialized shrink-wrapped solution that exists for this industry function (editorial directories, data publishing), then I will focus on the advantages and disadvantages of licensing.

Generally, you buy, (license) software when your data product is an ancillary part of your business – i.e., not your corporate specialty. Why buy in this scenario?
·         You lack specialized knowledge. Allowing an entity with specialized knowledge to help you is a mark of wisdom.  Your partner will help you to avoid “reinventing the wheel,” and will also help you account for blind-spots and complexities that could arise in the future – from the very beginning. You know news publishing very well. You know some things about data publishing, because you’ve done it (on an ancillary basis) for years. But you don’t specialize in software. At all. (DataJoe is a partner that excels in both data publishing and software.) 
·         You lack a large development team. Avoid resource drain by bringing in other, specialized hands to do the work.  
·         You lack the desire, drive, or resources to properly sustain an in-house solution. You are not a software company, and this platform is not your primary business. Why then would you want to take the huge responsibility of raising a software platform from infancy into adulthood? It always takes time and attention and intentionality. Your provider will take responsibility for updates, innovations, and enhancements so this stays off your plate.
·         You want to mitigate risk and explore your options. Once you start development on a home-grown solution, it’s hard to back out. Whereas, if you license from a third-party specialist, it’s easier to back out if needed.

·         Dependency. When you outsource a part of your business, it creates dependency. On some level, your destiny is now linked with the destiny of another company. This is the trade-off.  Choose a stable, good company.
·         Less flexibility. A software provider makes money by providing a turnkey solution with limited flexibility. You will have less control, by nature, than if you were to build your own solution.
·         Ongoing cost. Your costs will be predictable and controlled, but they will be ongoing.

Major principle:
Choose the right partner. At the end of the day, a software platform is just a tool. You need to pick the right one for the job, and then use it to full advantage.