INTRO
Johnny Levy, President |
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."
WHEN TO BUILD (CUSTOM)
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.
Disadvantages
·
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.)
* * * * * * * * * * * *
WHEN TO BUY (LICENSE)
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.
Disadvantages
·
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.