Everything to consider when rebuilding your website or app (and why the DevOps mindset is a good place to start)

Building a new website or app is hard enough. But rebuilding? In many ways, harder still.

The reason: when you turn your great ideas into technology from scratch, you’re starting with a  clean sheet of paper. No previous versions to worry about, no prior datasets to integrate. But as your competitive landscape evolves and new opportunities arise, the need arises for fresh iterations of your customer-facing tech. 

And that means dealing with the most flinch-inducing word in IT: legacy.

Legacy is what connects your current app to your next version. It’s your sales databases, your customer experiences and transactional histories, your reports and dashboards, even the personal preferences and ways of working that’ve built up over the years. All these sources of information need to be understood, evaluated, and re-integrated into your latest iteration, to ensure business continuity. And if you’re not careful this can be 90% of the whole job.

However, there are ways to make a decent fist of legacy issues. In this month’s article, we’ll share a few of the tips and tricks Purr uses to keep your tech humming along as it evolves, with a note at the end on a general approach that seems to work.

  1. Website or app? Think both

While the split isn’t clear-cut, your website and app usually occupy different roles: web as your shopfront trumpeting your wares to the masses, and app as a lean-forward experience letting your customers perform tasks. So they might not need refreshing at the same time. 

In our experience, though, concentrating purely on one carries risks. Your web and app should both convey the same brand attributes; it’s the start of omni-channel thinking. If you update one while leaving the other ‘til next year, it’s likely the customer experience will diverge, confusing your customers and damaging your brand. 

So at the very least, assign some time to assessing how a relaunch of your website would impact your app, and vice versa. Even if it’s just making sure your design attributes stay consistent across both.

  1. Technology matters, but human biases matters more

Ever heard of “bikeshedding”? It’s that tendency people have to spend a lot of time on simple things they have an opinion on, while ignoring 99% of the job. (If you’re building a nuclear power plant, non-experts want no part of it: the job’s too big and complicated. But if you want to build a bike shed…)

Bikeshedding is endemic when building websites. (Apps suffer a bit less.) The world and his dog will want input into the colours used, font sizes, what links should be on the main nav and what the front page should say. But the hard technical details of which data feeds and APIs it uses is often forgotten until the last minute. All these meetings and discussions can eat away at available resources, leading to cost overruns, deadline breaches, and suboptimal outcomes.

So above all, be mindful of bikeshedding. The “front millimetre” of graphic design isn’t the whole of the job; it’s the finishing touch after all the moving parts behind it are clearly defined. To maximise chances of success, stop the bikeshedding before it starts.

  1. Decide your goals, and whether the goalposts have moved

The worst reason for a new site or app is “we’ve had the old one for a while.” If it looks obsolete, by all means go for a reskin. But if it’s still delivering your goals, and supporting your business, why change what’s not broken?

By contrast, the best reason to change is that your business conditions have. You’ve entered a new market, your sector has undergone an upheaval, or you’ve simply seen a change in the way customers demand your products or services that merits a rethink. And if the landscape’s shifted, so will your objectives. (It’s something we’re deeply involved in at Purr – check our website over the next few months to see how we’re addressing a major market opportunity for our WordPress clients.)

So do this first: list what goals your refreshed site or app must answer, and get that list approved by all stakeholders. “Have an orange background” is not a goal. “Increase awareness by 20% among Millennial car owners” is a goal; so is “enable bank customers to speak to a human within 5 seconds”. Good goals are simple, concrete, and contain numbers. Setting them also protects you, the person in charge of the rebuild: if a colleague protests the web isn’t what he wanted, point to the goals he agreed before.

  1. Make sure it fits with other company processes 

The best sites and apps do more than present a storefront to the world. They integrate with business data, provide reports for internal decision making, become an indispensable tool of your business rather than just a signage out front. So it’s also good to see how the “processes” in your technology map onto the larger set of processes in your business.

Say one of your web goals is to engage 40% more customers. Does that mean less work for your Customer Service Desk, or more? What are those 40% buying, and does this create a need for a data feed from Stock Control? The better the fit, the more smoothly your business will operate – and the harder your site and app will work for it. 

  1. Take a considered view on feature migration 

Many companies adopt an all-in approach: every single data feed and API connection from before gets migrated to the new site, without exception. But every one of them needs ongoing documentation and maintenance, which costs money. And every one makes the project slightly more complicated. So another success factor is to decide what features really matter? 

If only ten users in a 10,000-strong list are using a feature, you may want to deprecate it – not re-implement it in the new site. This is something all Big Tech companies do, since every feature is also a cost. Keep on migrating features that your business no longer benefits from, and with every rebuild you’re prolonging fixed costs that don’t need to be there.

  1. Adopt a coherent project plan

Sort of obvious this one, but it’s amazing how many companies don’t do it. The principles of planning a customer-facing site or app haven’t changed in many years: organising principles, information architecture, and content strategy.

Organising principles are simply the basic concepts of your site or app, driven by what you want to sell. (For a bricks-and-mortar shop, for example, one organising principle might be “Womenswear on ground floor, Menswear on first”; another might be “casual clothes on the left, formalwear on the right.” What decides this is your customers, and their basic preferences.

Information architecture involves your customer journey, and how your site or app supports it. This is where your sales and marketing team need to be most closely consulted: how customers learn about you, find your site, and what they do when they get there. Fortunately, it’s also a fantastic guide to what your site or app needs to be.

With OPs and IA decided, content strategy is what you fill your creation with. (Usually, this applies more to your site than app.) This is largely decided by your company’s tone of voice (ToV), design guidelines, and information your customers want, sequenced to nurture them along the sales funnel. Purr has only one piece of advice here: use a Content Management System (CMS) that lets your designated people post and update easily.

  1. And only then think of technology choices!

There are many ways to skin a cat. And even more to rebuild a web app. But it’s important to only sort through this list after all the steps above are complete. 

After all, the best technology platform to build on may be a new entrant to the market, something you’ve never heard of before but which doubles your ROI at half the cost. Using the same old platform again may offer some upfront cost savings – but will those evaporate over the three-year life expectancy of your new site?

That’s why it’s important to work with a full-stack developer with knowledge of a broad range of technologies, like Purr. We’re not wedded to a single tech platform; we prefer to listen to your needs first (defined by the points above) and then make our recommendations.

How to do it: adopt a DevOps model

You’ll notice a common thread to the above: treating the needs of all stakeholders – internal, external, technological – as one. That’s the objective of DevOps. An Agile-style approach to creating technology where software developers and business operations aren’t separate teams with walls between them, but work together every day. with constant checks and balances preventing the slide into silo thinking.

If you want your new site or app to truly answer the needs of your customers – think DevOps. Purr does.

CONCLUSION: broader, deeper, better

We hope this article’s given you a different perspective on your rebuild, and why it’s about a lot more than a whizzy new graphic design. It’s about matching your customer’s journey to your technology, answering their needs at every stage; it’s about making sure your site or app is a true business tool, not a window display. And most of all, it’s about a focus on your market – and how a rebuild can take advantage of opportunities that weren’t there before.

As a full-stack tech agency with design and marketing smarts too, Purr can help with all of this. Why not book a call with our talent-rich team across the UK?