Why Custom Code is the Road to Hell for Cloud Developers

Jake Adger
Jake Adger
Director of Product Marketing, Coupa Software

Jake is a Product Marketing leader with extensive software experience including product strategy, customer needs, requirements, positioning, collateral, technical marketing, pricing, and field enablement.

Read time: 6 mins
Picture of a Road

In my last article, I wrote about why worries about integrating cloud-based Software as a Service (SaaS) should be a thing of the past if you’re dealing with a true cloud vendor.

In a true cloud SaaS offering, the vendor does not customize their code to customer requirements. So, with every integration, they are integrating something familiar and unchanging on their side to whatever the customer has.

If the vendor has custom code, then all bets are off; then they’re integrating two custom systems and it is a custom integration, subject to all the risks and problems thereof, and not a true cloud offering.

The dividing line is code. A true cloud SaaS offering is written on a single code line.  Customers can configure the software every which way, but they cannot customize the code for their businesses or to install it on their own servers. Consistent code makes maintenance easier and lets the company focus on innovation.  Coding for cloud-only delivery lets the vendor design for super-efficient, secure, and scalable operations. Therein lies the meat of the cloud SaaS value proposition. Customized code is the fastest way to descend from the clouds and head in the other direction.

If you’re already convinced, you can stop reading right there. If you’d like to understand exactly what I mean by “single code line” and why it matters so much, read on.

Why a Single Code Line Matters

Imagine you run a 200-page website and you have a simple footer that is the same on every page. It has your address and phone number, copyright, and maybe a few other pieces of information. You’ve seen this type of footer many times.

Let’s say you want to make a change to your phone number. You go to where your footer code lives, you change the phone number and the new phone number appears on all 200 pages. This is possible because you have a single code line for your footer.

On the other hand, let’s say HR wants a customized footer. Their reasons are very compelling, so you give it to them. Legal sees that, and then they ask for some customizations on different footers around the site. Then marketing gets wind that there’s a custom footer opportunity and they want one too. Now instead of just one file in a central place that defines the footer, you have multiple footers in multiple places and life is a lot more complicated.

Now if you want to change your phone number you have to go to each and every place to make that update. You have to create some way of keeping track of all those places to make sure you don’t miss any. And then you find one that is different and then you can't remember why it is different. So can you update it to the new version or not? Confusion ensues.  Now you’re spending time and resources keeping track of all these versions, instead of creating fresh web content.

The Plot Thickens

That’s a very simple example, much simpler than what happens with software, but you get the basic concept. Let’s make our analogy a little more complicated.

If your footer just has text in it, that’s data. Let’s say it also has some links in it, maybe to your “About Us” page. Now you have both data and functionality; the text is data and the links actually do something. If you start customizing your footers, you will have both data and functionality spread all over the place, which is similar to what happens once you start down the path towards customization in a software development environment.

In software, the functionality and the way that the data is stored are two different things but you want to have them uniform across all the customer implementations of the software, the same way you’d want a single footer across all your web pages - so you can make your updates in one place and have them go everywhere.

That’s why if you’re a webmaster you don't allow people to monkey around with the footer, and why you can’t really lay claim all the advantages of SaaS if you start doing custom code.  You lose all the efficiency, scalability and cost advantage of the single code line. This is the road to hell for a SaaS company. It’s not just integration that becomes considerably more time consuming, difficult and expensive. Everything does.

A Scalable Model

The SaaS subscription model only works when you can sell the same thing to a lot of customers. SaaS companies aren’t collecting big up-front fees. They’re investing a lot in R&D, but for the business to be viable, they have to sell the resulting product over and over again. If you start building code that is only used by one customer, you’ll ruin your financial model.

Still, there are plenty of SaaS companies who do this. The main reason is short-term gain. It’s very tempting if someone offers you a million dollars to have any footer they want on their webpage to take the money and worry about this scale problem later.

It’s all cool until you have to change something and you realize you can't because you’ve created all this complexity. Meanwhile you spent the million dollars and now you have some pretty big, hairy problems that need solving.

We’ve talked about what it really means to be a true cloud SaaS company at every one that I’ve been with, and I think this is what it boils down to: You have to be committed to maintaining that integrity, that single code line, or you’re not a SaaS shop, you’re a custom development shop and that’s a completely different business model and you can’t claim all the advantages of a true cloud SaaS offering.

Those typically include lower up front costs, lower total cost of ownership, easy access to frequent software upgrades, easy deployment across multiple locations and fast, easy integration, which is where I started this whole discussion.

Why is it so much harder to integrate custom code? It’s a bit of a stretch to extend our single code line website analogy to integration, but here goes: Integration is all about getting information from one system into another.  So, if you have a footer consisting of two sentences and you want to send that information to another footer via integration, that will be easy as long as you have a two-sentence footer on the other end. But say some of your web pages only have a one-sentence footer, and you built your integration to send the second sentence. Your integration is going to break, because the expected data format isn’t there.

Now in reality, you would probably know when you are building the integration that you have some complexity to deal with, so you have to invest time and effort in managing it. This is what makes an integration more time consuming, costly, complicated and prone to errors. But, if you’re dealing with a true cloud solution, integration should not be a big concern. So if you’re buying SaaS, you should make sure it’s true cloud SaaS. Don’t take any wooden nickels.