We use cookies. You have options. Cookies help us keep the site running smoothly and inform some of our advertising, but if you’d like to make adjustments, you can visit our Cookie Notice page for more information.
We’d like to use cookies on your device. Cookies help us keep the site running smoothly and inform some of our advertising, but how we use them is entirely up to you. Accept our recommended settings or customise them to your wishes.
×

Complexities of Creating Efficiencies at Scale

People can sometimes demonstrate a psychological tendency to measure the cost of a website or piece of software (i.e. a service) through the same lens as that of a computer or other good. Underlying this is likely a desire to believe that the concept of “efficiency of scale” applies perfectly to services and products equally. The reality, however, is that this is not the case. 

Still, some companies underestimate (or overlook entirely) the customisation required to build their solutions, which can have a significant impact on expectations being met.  

As discussed in the first article of this series, “Project planning: Customising solutions and weighing up off-the-shelf options,” working in collaboration with the development team, being clear about requirements, expectations and, most importantly, the budget is the first important step to setting up your project for success and ensuring the estimated cost is as close as possible to the actual cost. 

What you also need to understand is that the technology industry is simply moving too fast for “efficiency of scale” to be viable. By the time most developers become familiar enough with a particular technology or approach to achieve any efficiency or real velocity, a newer version of that technology or approach is already available.  

Even large enterprise platforms, purportedly there to make development easier and quicker, also evolve rapidly, and each new release presents its own learning curve, challenges, and requirements. Coupled with the fact that nearly all client requirements are not quite out of the box, this makes for a potent recipe for built-in cost escalation. 

 

The History of Next-gen Websites 

The evolution of how websites are built is a great example of this. Websites first started with developers using simple HTML and CSS. There was no integration, accessibility, browser and device compliance, or penetration testing to consider. Content authoring wasn’t even a thing: developers simply wrote the code and the content together (since “code” was just formatting the content and making it available online). 

Over time, developers got sick of this and built CMS’s so authors could do it themselves. Then people started to worry about how their website worked in browsers that weren’t Internet Explorer, so development started to involve cross-browser testing (ensuring that content and functional features would work across different browsers). As a result, building the same things as before now took much longer, just because there was more work involved and because different browsers demanded individual ways of doing things. 

While browsers eventually standardised, next came the “m-dot” phase of mobile website development. This meant building two or three websites instead of one became the norm, depending on whether you wanted to support mobile, tablets, or both. And when that standardised, it became a choice between these multiple variants or developing one “responsive” website that was flexible and smart enough to “respond” to the screen size it was showing on. Responsive websites, great for the end-user, typically need to be designed from the ground up, and every “feature” must be tested in four or five different ways to ensure it works in every possible scenario. Somewhere along the line, accessibility became important too, and clients started to require that their sites be “WCAG-compliant” (a one-liner in most RFPs, most clients don’t realise the effort involved in this can be in the tens and even hundreds of thousands of dollars). 

Responsive websites eventually became a standard, but this standardisation certainly hadn’t reduced the cost, not when compared to the old HTML and CSS websites of the early days. And of course, then digital behemoths like Airbnb, Spotify, Xero and Netflix started to spend tens of millions annually on their customer experiences. These millions bought them user interfaces with rich, interactive transitions, real-time updates and behind-the-scenes API calls instead of tedious, old-fashioned “page loads”. The concept of waiting for the page to load became taboo, and every business suddenly needed the same experience, but preferably without the cost (of a team of hundreds of developers on their payroll).  

In the old days, Javascript was used to deliver animations and transitions. But delivering these kinds of user experiences and interactivity with native Javascript was prohibitively expensive. It took hundreds and thousands of hours to try to replicate what these digital behemoths did, and so eventually Javascript frameworks like React, Vue and Angular were released to save the day. These allowed developers to piggyback off existing technology and get richer experiences to market faster. But frameworks had a steep learning curve and required a complete shift in the development paradigm; this required new skills, and new job titles.  

Big platforms were also slow to keep up with this new way of implementing the user interface, meaning many of these benefits were slow to be transferred to the real world and early adopters were left pushing painfully against the grain, losing any benefit they might have hoped to achieve in the process. In fact, even today using modern front-end development techniques on large platforms designed to help people “author” websites is a challenge that most developers find frustrating, time-consuming, infuriating, or (at worst) impossible. 

And if you followed all of that, then remember that what I’ve just shared was only what happened in “front-end” web development. We haven’t even spoken about back-end development.  

 

A Cutting-edge Digital Experience 

All these things represent a constantly shifting landscape. For every step forward in cost savings through standardisation and component libraries, there are two steps backward in terms of new expectations or requirements, or moving goal posts concerning devices, data privacy, security, cookies, accessibility and more. 

That’s not necessarily a bad thing. Accessibility, in particular, is a fantastic thing; the benefits of an accessible website extend far beyond people with disabilities. But it all adds up to more development time, more testing, and more customisation (when your ‘off the shelf’ components aren’t WCAG-compliant, for example). Meanwhile, technology salaries are also increasing at some of the fastest rates in history. 

All of this adds up to a situation where as technology evolves in power, user expectations evolve with it, and so it never really gets that much easier to do what is “expected”. If software or websites were being built today the same way they were twenty years ago, with the same expectations, then things would undoubtedly be far cheaper, and easier, and ‘out of the box’. But they aren’t: websites and software are becoming more and more complex to build, and therefore more and more costly to put together. Instead of getting more cost-effective and more common to create over time, they are going in the other direction. 

Ironically, industry-leading digital experiences can bring considerable value to a business. Netflix is a perfect example of this. And yet businesses seem averse to paying for the time it takes to have experts assemble this experience and to do it properly, instead insisting that somehow it should come pre-packaged and ready to install on a server somewhere. If it was that easy, wouldn’t everyone be doing it? In fact, some companies will happily write large cheques for advertising campaigns that drive a slight increase in revenue, but resist investing a fraction of the cost of a single ad campaign in a class-leading digital customer experience, even though there is abundant evidence showing that the latter will provide far better longer term financial  (not to mention end-user) outcomes. 

So the next time you find yourself wondering why the quote you just received is so expensive, think about the value you’re going to get from it, and think about the work that has to go into it to do it properly. Don’t cut corners. Custom builds have always been, and will always be, expensive. But class-leading digital experiences are almost always bespoke, never cookie-cutter, and can be among the best investments your business will ever make. That is, if they are done right. 

 

Christian Brenner has spent over two decades building enterprise websites for businesses and organisations. He is currently the National Head of Technology for Merkle Australia, the country’s leading customer transformation partner, empowering brands to create distinctly better experiences. 

This article is the first in a five-part series. Follow Merkle Australia on LinkedIn for more.