This article by Lendesk’s VP of Business Development Lee Noble originally appeared on LinkedIn Pulse.
The year was 1999, when four founders including former Oracle executive Marc Benioff started Salesforce.com, said by many to be the first ever SaaS (Software as a Service) company. At the time of writing this, Salesforce (NYSE: CRM) has a $48bn market cap, and I think that is indicative of the overall changes in the industry.
I would be doing a disservice to those founders if I were to write on this topic without paying homage to Salesforce first. Since those early days of the first hosted applications, SaaS has become a popular way for businesses to manage technology costs, making monthly or annual payments for software services of all kinds. Odds are, you or your company use several SaaS apps: Google Docs, Dropbox, the aforementioned Salesforce, and Hootsuite are just some of the “apps” that have already cemented their places as line-items in many enterprise company budgets. In 2014 Slack, a communications and team management tool founded by BC native Stewart Butterfield, famously became the fastest SaaS company to get a $1bn valuation, and is now valued at more than double that figure.
And yet with all the hype surrounding SaaS, some companies—particularly ones with ample resources—still opt to build their own proprietary tech to solve their unique needs. So which is the right way? Is it better to entrust your data to a software company and their SLAs (service level agreements), or to build your own tech in-house? Let’s take a look at the pros and cons of both, and see where we net out.
Build vs. buy: The organizational dilemma
Before we get into the comparisons, two key considerations that I think are important:
1- Are you in a completely unique business? If not, there’s probably someone else who has attempted to solve your problems before and you can learn from their efforts.
2- Will technology be a competitive advantage or just help in making operations run more smoothly? If it doesn’t help you deliver better quality service or support your business processes at a lower cost, then is it the right investment to be making? For example, It’s probably not a good investment for a medium-sized corporation to be building their own secure, cloud-hosted document storage service when Dropbox costs just $13/month for each user, for a terabyte of storage each. Simple economics, but there’s a lot more to consider than just price.
The advantages of “buying”
Lee Noble, VP of Business Development
As I said above, most business problems are quite common, and have been solved by technology already. Payroll, sales compensation, team management, logistics; there’s a tool for every job, and it’s probably already full-featured enough to solve most, if not all of your needs. In fact, if anything it may have more features than you need, and the challenge will be to find the best way for you to use it.
With SaaS applications, the creators have a business objective to remain relevant and useful for the long run. As such, they build integrations with other services into their product using APIs (Application Programming Interfaces) and other add-ons. This is what makes it possible for your Hootsuite contacts to be ported over to being Leads in Salesforce, or for your Shopify store to export your customer lists to Constant Contact or MailChimp. Put simply, SaaS creators are forced to build and support a product that works and is valuable to you, so if they’re looking at the big picture, they play nice with others.
A case for “building?”
Let’s say you’re a real estate company, with thousands of Realtors country-wide. They are beginning to get vocal about demanding a more streamlined, mobile way of managing their business. As more young people join the industry, the demand for better technology escalates; spreadsheets and Outlook aren’t cutting it anymore. Your competition is outpacing and out-recruiting you by promising a more technologically advanced workplace. What do you do? Do you build an application of your own, and experience the pride and joy of seeing your own icon in the app store, or do you mandate an existing SaaS solution, making it the standard and training your people on it? In this context, the question of build vs. buy becomes more challenging to answer, but for me there’s still no question.
In support of “buying”
At this stage, my bias should be quite clear, so I’m going to abandon all objectivity, if you’ll excuse me. If when you read the mini use-case involving the real estate company above, you concluded that building an app was the answer, let me shed some light on what you might be missing. We have already set aside the cost comparison, so let’s assume you do have a budget of hundreds of thousands of dollars with which to build a tool (you didn’t think it would be cheaper, did you?) that suits your needs.
For starters, you’re going to need a team to build it. And to do that, you have to compete with software companies to recruit talent. You better have a kegerator, flexible hours, a ping-pong table, t-shirt policy and stock options—or you might not be able to compete. Okay, those are optional but you get the idea.
More than likely, you’ll be hiring an agency or external team to do the build, and will be subject to their costs and terms. Remember when I said hundreds of thousands? You’ll be scanning the line items, scratching your head at line items like “user experience design” and wondering why they cost so damn much. The answer: because the absence of that design results in a shitty product.
Talent: The single biggest factor
As I’ve eluded to already, the biggest differentiator in the question of build vs. buy is talent. Software developers are incredibly good at what they do. Not to take anything away from agency contractors, but consider for a minute the difference between a team who has cashed your deposit check and is building your app, and a company whose very survival depends on building their product and their company fast. What’s more, they don’t stop when the product ships. They keep going: fixing bugs, responding to support requests, and ensuring that the product remains secure, up-to-date, and online. They barely sleep, and they constantly strive to make their product better in the service of their customers.
How do I know this? Because I see it everyday. I’m not a software developer, but I do happen to lead Business Development for a software company. We are creating a new loan origination platform called Lendesk. I have to make smaller build vs. buy decisions of my own all the time, and I’m guided by some of the brightest minds I’ve encountered in my time on this planet. The way a software team works is pretty special. Not only are they always improving upon the product they are building, but they constantly review their own processes to make sure that they are working as fast as possible. Team huddles, retrospectives, security checks; all for a product that hasn’t even had its public launch yet. It’s just my bias, but my experience tells me that these guys are running circles around any loosely assembled in-house teams working on the inside of established corporations building proprietary products. I suggest focusing on your area of expertise and what drives revenue for your business and leave the complicated task of software development to those of us that specialize in it.
Our product, Lendesk, is currently in private beta, and is available for private lending companies to review and try. If you’re interested in seeing what we’ve built, send me a message and I can arrange a demo. Chance are, we’ve already built the solution to your technology problems.
The post Build vs. buy: Making informed decisions about enterprise software appeared first on Lendesk.
