Relaunching Websites: The Agile Way (an Iterative Approach)

In a fast-paced business environment, it's no longer acceptable to wait months for a website relaunch. That's why it's time to say goodbye to the traditional waterfall approach and to go for an agile relaunch! In this episode, we dive deep into how an iterative approach enables faster, better results and more flexibility, to take your next website relaunch to new heights.

Highlights
00:00 Intro
02:06 Agile advantages
04:12 Rebuilding step by step
08:37 Scoping & budgeting
16:36 Focusing on ROI
18:34 2 page builders in 1 website
20:39 A matter of trust
22:43 Small scope multi-phase launches

Steffen: 0:00

And then you can partially relaunch and measure its success, and as long as the return on investment is bigger, then you just keep on doing these things. Today we're talking about relaunching websites and iterative approach.

Dominik: 0:14

Hey, another follow up to our series Is that the last one, Steffen.

Dominik: 0:19

Maybe. What do we mean with that? Well, when clients come to us and want to relaunch their website, a lot of them usually have in mind to do an entire relaunch of the whole website And then at point X, like migrate everything and put the new side life and have everything done in one go right. But as a lot of like developers know and also like from product development, we know that an iterative approach is usually preferable or leads to better results, because you might not, like put emphasis on the right things, or maybe some of the assumptions that you made are not correct or whatnot.

Dominik: 0:57

And with iterative I also mean, like agile, and you can basically apply the same thing with relaunches and not relaunch the entire website at a single point in time, but take different parts of the website and relaunch them independently, right? So you maybe start with, for example, the articles. If your main pain point for your current site is that content editors have a hard time adding new content or that it's not so ideal the way they have can write or publish stuff, then you could say, ok, let's focus on the articles on the block first, set up a whole environment with that and then integrate that in the existing website And we have one podcast where we cover exactly that, like integrating WordPress into other websites, and this is basically the same thing. So you could, for example, use a reverse proxy to then only serve everything under slash block by the new, redesigned, relaunched website and the rest would still be the old system.

Steffen: 2:04

Yeah, Yeah, i think one of the main advantages of doing something like this is that you don't have to wait for so long for your relaunch to happen. Actually, because we have some clients most likely fast pacing clients, like startups, that want to move fast yeah, right now and want to make adjustments and make extensions to their site at this very point in time. And then, yeah, if you start a full relaunch process for the entire website, this, first of all, it takes time, like the way we approach website relaunches with doing proper UX strategy, analysis, research, design first, technical concept and then custom development. This easily takes three to six months from the initial kickoff of getting together to the actual launch, because what happens in between a lot of also feedback rounds, right, and adding all the content and getting clarity and so on. And when you want to do things quicker, like you, many, many times you start working with your existing website or you continue working with your existing website, and that's sometimes where we then jump in right.

Steffen: 3:38

Let's say, we can also do that, like we can provide support on an existing WordPress website, if it's WordPress, and then make adjustments there, optimizations there, but at the same time prepare to relaunch a certain part of the website. You name it. Wherever the biggest pain point is, that might be the block. Many times this might also be the landing pages like to create quickly new marketing pages or integrating forms or whatever. And how we did that a couple of times is that then, step by step, we kind of relaunched more and more parts until we relaunched actually the entire website. But how long did that take then? I think the whole process was usually kind of intense, right, and the whole process still took at least also I think probably half a year until, like, the whole website was then relaunched. Sometimes it's even longer, but with the first results being much, much quicker than the first results being there within like one, two, three months right.

Dominik: 4:45

Yeah And like. Sometimes it can also take a year or two to move an entire website and to relaunch an entire website, and I mean a lot of the times. We also get themes or like takeover WordPress installations that are built with like multipurpose themes or like WordPress, like with the Wizzywick builders or whatever. So, like Elementor or a Divi or what else, like you know, beaver, there are so many of those and companies realize that these setups are often brittle And while they offer a lot of flexibility, it's not so easy to get to stay in your well-defined guides or CI or whatever. So, yeah, then sometimes we overtake these and then switch, like, maybe for a certain post type, we add our Flint components and the component-based approach, and then it takes step by step. We can see, okay, this makes sense to do next, then migrate the content, then make sure that everything is working correctly, see how actually the conversion is or what your metrics are for these websites, and then take again what we've learned from that to apply to the new set of components. Right, sometimes it's these post types, but sometimes it's like the landing pages, and in such a case it's actually like you wouldn't integrate you probably wouldn't integrate the new WordPress with the existing website, but set up WordPress as, like, the main entry point and then integrate the old website into that new WordPress system, right? So, because then you would have your homepage served by the new application and, like all the landing pages or the static pages, they could also then be served by that. And for then the post types, like news or articles or like whatever, you just serve the old application. And how you decide to do that is, it depends like either the pain point stuff, right, so you check what is your biggest pain point and then you go from there, or you can see what is the MVP like, what are really, what is the minimal set of changes or minimal things that we have to implement in order to just have something right, and for that we would like maybe have a look at redesigns or maybe talk to the client about that and see what kind of components.

Dominik: 7:40

So what is the set of components that we need for specific post type and post up, also being landing pages or A static pages, but also any other custom or build in types. And then we check, okay, where is the this set, where is it the smallest? And then we say, okay, then let's implement that first, and because everything usually starts with a base design, right and things like that, and you always need that and then you can see, like, how many components Do we need? we need to implement that, what maybe other functionality is there that is not like design related And so on. Yeah, so lots of things to consider, but Usually also, as I said, i very much prefer this way of working. The problem is it's harder to plan it in advance, right, and that's what's always the case with like an, an iterative or agile approach that you don't usually have these fixed price models or whatever Usually like. Doing this in the fixed price is a lot harder than a complete relaunch like all in one, right.

Steffen: 9:01

Yeah, absolutely, that is very hard. Like I think it makes a lot of sense to do some kind of scoping in the beginning, right, you should definitely do some kind of scoping Workshop so you can define which post types you're going to start with and what kind of pages and what menu structure.

Steffen: 9:20

And you also got to talk about stuff like integrations Which kind of other systems are you using and which should be integrated like Hub spot and which which shouldn't? like and that could also be a spot like, because, like, if you're having your blog on Hub spot already, that might be an easy choice to just keep it there for now and to focus on the other more effective areas, right, and to then define, yeah, a roadmap for the first initial set of components landing pages, the strategy and so on And then you might be able to to set some pretty good scope on that. But as soon as it gets into the integration, like connecting the old and the new systems this is this is so hard to assume in the beginning Or to anticipate what kind of things might go wrong, where, where you might have additional challenges. And also, when it comes to integrating these other platforms, you might want to make sure that these still feel like one website, right. In our previous episode about migrating content, we also talked about not migrating content, that this would be an option, specifically when it comes to archives like news or press archive, and of course that's also would be a rather easy thing to keep that separate And to then redirect all that traffic or like proxy all that traffic, to this old system. But if this old system does have an entirely different main navigation, with different items, with different structure and so on, then this might be very confusing for people. So at the same time you might want to go into those old systems and make adjustments there, like kind of adjust the main navigation to match the new main navigation. So it feels more like one thing and then step by step And yeah, and coming back to the topic of effort, certainly this, this is more effort than doing just relaunch, but the advantage is it's faster.

Steffen: 11:35

You can get more things done quicker, like in applying new things to your website, rolling out new things, and you can also learn a lot more, because what we've also done is going back and forth a lot with the website relaunch, like sometimes we even built stuff and launched it and removed it even a couple of weeks or months later again, for several reasons. But this is a benefit. I think that you can make these decisions more easily and put focus on that instead of just having your fixed, defined scope in the beginning, three to six months later. Here it is and now, and only then, you start implementing change right, and we discussing things, because I always like to say that the website is never finished. Only when it goes live, it starts living and breathing and you will start to make changes. Typically, anyways, if you were, especially if you're working with your website as being your main platform, your main hub that you want to nurture also.

Dominik: 12:49

Yeah, totally, it's finished when you take it down. Yeah, website is finished offline. Yeah, so if you look at it that way, you might think that you're because you're only relaunching something right, that the scope is actually pretty clear and that Fix price projects or fix scope project should like be very likely to succeed, and so on. In reality, like there is a reason why you are changing while you're relaunching right and what you want to improve, you can't really anticipate. So why this iterative approach gives maybe a little more effort, a little more uncertainty what the outcome will be. It will definitely, if you do a good job, be a product that is better. So the quality of the product that you get at the end is will definitely be higher than in just like one off A relaunch right. So that's like the typical, like agile advantages, that that you have, you also have with this approach, yeah. So just, i don't know if you, if we want to take this out of you want to talk about this. But What? like a lot of our clients Or let's put it that way we have different kind of clients, right, and we still do these fix price projects and so on, but then we also have maintenance support and we have like for service Contracts and in full with our full service partners. We basically get a budget for a year and then like work for them with everything that comes up. Basically, we usually have like predefined tasks, right, so it's not that we just sit down, wait till they call us. But in such a relationship A relaunch can actually a lot of the times be And then this iterative relaunch can be the best thing that you can do and that you can focus on right, because also Sometimes we have taken over these websites that have like pretty brittle setups or Where some things don't work as smoothly, and then we are just there to improve that and to make things work better.

Dominik: 15:21

But honestly, like in some cases when certain plugins are used, when certain configuration is done or when things work programmed in a certain way, sometimes it is easier to just Do it like start from scratch or like make, like implement these parts in a new way, and also the way that we like to work with flint and with components and And the modular approach and so on. And yeah, that means that a lot of times also, where clients came to us for maintenance only, we ended up relaunching first parts of the websites, and then usually they are so excited about the new setup that they want more, and then we migrate more, and then at the end, we migrate everything. And actually we had it also in the past, where then At some point the client said, yeah, now everything works perfectly, so we can take care of it ourselves. Now, thanks, so, which, of course, but in the end, everyone has has benefited from that right, and this should always be the goal.

Steffen: 16:36

I would even go as far as saying most of the times this iterative relaunch approach wasn't planned right from the beginning, but it more like it happened throughout time, because we were first task with making optimizations, improvements, adding features, and we talked about this general idea of like maybe relaunching the website at some point, but it was more a result of agreeing on a close partnership where we do have the budget and the team set and we collaborate very closely together and then doing a relaunch within that framework agreement is not so much about money anymore, but it's more about time and about organization and priorities. And then we typically started implementing new features and the best case scenario We do have very great analytical data made, that be in regards to the generation or, when it's a shop, in terms of sales and so on, conversion rates and then you can partially relaunch certain things and measure its success. And as long as the return on investment is bigger than what you did and you're continuously adding value, then you just keep, keep on doing these things and start relaunching more and more Things of that page. I remember also other projects where we actually didn't set up a separate new WordPress website, but we integrated the Flint approach what we call the Flint approach, like the ACF, component based approach Into an existing WordPress website. And why? strategically, for infrastructure. This isn't my favorite thing because you start mixing things and so on. It's still a turnout work very fine again and again.

Steffen: 18:32

And then sometimes we even have the situation where we have one Post type, and this is this is probably an interesting one what if you want to relaunch one certain type of content within a website, then you also you have the big challenge that You need to migrate that content to the new type of technical system, let's say component system, going from a visual page built a component system. And how do you do that? well, then you need to copy over all that content right and recreate that, and that can be fine if it's Dozens of pages. But we've had the situation where it was like kind of like hundreds of pages And then again you would need to end up with OK, if we want to switch to the new system, we got to wait until everything is technically migrated. But you know Is technically migrated. But then you can't technically migrate that because it's not structured data, it's visual page fill the data.

Steffen: 19:35

We talked about that also in the early episode. But you got a manual to that And then you got to wait for it for months and months until someone has done that. Until then you can't use the system. So What do we do to prevent that? we actually had two systems on the same post type at the same time and had a toggle within that system so you could say which page builder approach you wanted to use. Or basically we said like when you create new pages you could use the new system right away, but the old pages were still available with the old system and then, step by step, our customer could Create new pages, replace the old pages and so on, and we just wait, no matter how long it takes, until point where all the pages All to the new system and then just switch off the old page builder system and can then start deleting that that code also from the code base and from the database?

Dominik: 20:37

Yeah, totally like. Just one other thing that came to my mind. I mean, let's face it, who like which clients actually have? like, if you have a really like a massive what press, what, or massive website with lots of content, who actually has the Budget and also the willingness to say, yeah, here are i don't know x amount of euros or dollars. Now please take Half a year. We will continue to work with our old system for half a year, which we don't like anymore, and please just Make it like be done in half a year and then Will migrate or we will do the relaunch right.

Dominik: 21:25

So, like it's very unlikely that you find a client who's willing to put in all of that money And the insecurity and what not to do that. So that's why also, we've noticed that With this partner based it to full service, iterative approach usually the client has a budget, like a fixed budget that they can spend in a year or that they want to spend in the year for improvements to the home page, and if they trust us with that, we can figure out together also but with our expertise, what is the best way to invest this and like if they then see it's working well, we have some more budget, let's put on like, let's I don't know turn on the boost kind of, and put on more people to to finish something quicker and so on, but Like again everything is in a smaller scale and also like shows immediate, immediate feedback, and this is like what's really usually a benefit for everyone as well.

Steffen: 22:43

A little alternative approach, though, to relaunching aside, with the old side being still online is just like Deciding on a smaller scope to relaunch and power off everything, all the old stuff. But this obviously only works if you don't need all the old stuff, if you don't Need it for SEO or for each generation, so on, if you can afford that, and this typically only is true if the old website actually did not provide that much value yet. But the reason for the relaunch is that you want to Get a lot more value out of your website. You finally want to start working with the website in a very meaningful way? Yeah, or you can afford again to lose a lot of not so important, low quality content or something like that.

Steffen: 23:34

And then still, yeah, many people times people ask if we can also launch still in an iterative approach, meaning in multiple phases, like. Like, when we want to launch first the homepage, the main company pages Of the website and contact lead generation form. To get started quickly was measuring the results, but something like the new blog or a glossary or the events section. This might only be launched later, like. It's still part of the scope, but we deliberately say this won't be part of the first phase of the launch, but we just launch those things A month, two months later or something like that and then everyone has more time to prepare the development, the testing, the content of that. That's many times also one of the biggest factors when it comes to Creating new stuff and like launching new section to post types that it just might take a long time to prepare all the content for the goal life, because you don't many times want to launch a new Block was just like a single post or something like that.

Steffen: 24:48

So that's also what we like to do and this is very easily possible with also our approach with Flint, with components, because making a new deployment, adding a new set of components or a new template, it's not a big deal like because the interference between components and templates is not big like. Everything is pretty much isolated. We can even delete components very well without breaking things or having Things go wrong in in a very unexpected way. So This works very well, very, very easily and we totally Advice to do that. But again, you gotta bring probably A bigger budget. This is a typical triangle right off time, quality, money That if you want to be quicker, you're gonna probably need a bigger budget, and quality isn't something we compromise on, so it's to be only one of the two time or money.

Dominik: 25:47

Yeah, that sums it up. yes,

Siegfried, deploy!

Relaunching Websites: The Agile Way (an Iterative Approach)

Listen to this podcast on