291 – The launch

291 – The launch

‘WordPress Business Bootcamp’ with Nathan Wrigley and David Waumsley

These shows notes are best read in conjunction with the podcast audio.


GoDaddy Pro

Welcome to another in the Business Bootcamp series where we relearn everything we know about building WordPress sites and running a web design business from start to finish. 

We are on episode 6 (the last) of season 3, where we are looking at the technical build, and today we are discussing ‘The launch’, (whatever that is).

Nathan and David are taking contrasting approaches to getting our new businesses running and our first client’s site built. She is a new lawyer with no previous site, and is called Ms. A.


Nathan:
Going Traditional with fixed pricing. He has presented a proposal and contract. Set some expectation on the plan with has a deadline.

David:
Going agile. Minimal viable website with ongoing improvements that are in collaboration with the client. Strategic and data driven.

Episode 6. The Launch

The problem (or things to get straight in our own minds)

  • What do we think a launch is (and is it the same and what the client thinks)?
  • What is the client expecting from it?
  • What does it signify in terms of the design client relationship?
  • The difference between a new project or business and a redesign.

Traditional V the agile launch


WP Builds Black Friday Deals Page

With a traditional build, the launch would probably be the end of the project. Probably done after the last payment is made with perhaps a period, allowing for snags.

This is often the easiest bit in my opinion, as going live was after we’d agreed to do that, and so all of the moving parts have stopped moving and it’s just a case of amending the DNS etc. There’s a nice sense of relief here as well, like… ‘job done’.

Nathan

There is room for some discussion here. I recently did some stuff on ‘coming soon’ pages.

Obviously their existence assumes with new domains (like our lawyer’s) the DNS stuff is done before launch. Whereas the tools for building locally suggest the opposite.

 I now have an approach where before I did not – in fact what I did was plain stupid!

There is something lovely about releasing something.

David

With agile it is probably when the first viable page can be released and is the start of the design process. It is likely to follow on from some prior research.

The downside of the agile launch is that it might not be the best first impression for visitors. 

But then, it is not done to coincide with an offline office or shop launch. The main aim will be to give the site some early standing with search engines.

The downside of the traditional approach is that it can get caught up in the need for perfection based on guesswork. Some websites go through endless iterations for years behind a coming soon page.

The pressure is on the traditional designer to make sure everything is working fine on what could be a long checklist.

Launch horror stories

  • Not getting paid.
  • Just complete silence, like total crickets!
  • Never happening.
  • Forgetting to set WordPress to let search engines index the site!
  • Or the robots.txt file disallow all! Or had the http version of the site in ‘Settings’!

What’s on the checklist?

Common to traditional and agile.

  • Security and backups.
  • Analytics – reporting visitor numbers and user behaviour.
  • SEO – can be indexed, meta data, no follows, alt-text and redirect 404s etc.
  • Legal – accessibility, privacy.
  • Copy – accuracy, selling and grammar.
  • Performance – speed tests.
  • Browser and device – responsive stuff.
  • Functionality – contact forms, email sign ups.
  • DNS – best to start this process a few days in advance to set the TTLs up correctly, although this seems to be less of a thing these days.

Other matters

  • Client training (in the next series) and handover.
  • Care plans – this seems to be the holy grail these days, but I’m not too sure how long this is going to last given the tightening of the worldwide economy.
  • UX testing.
  • Promotion for launch (social media teasers, Google/Facebook ads).
  • Stress testing (can servers manage the demand).
  • Penetration testing.

Please leave a comment...

Nathan Wrigley

Nathan Wrigley

Nathan writes posts and creates audio about WordPress on WP Builds. He can also be found in the WP Builds Facebook group.

The WP Builds podcast is brought to you this week by…

GoDaddy Pro

The home of Managed WordPress hosting that includes free domain, SSL, and 24/7 support. Bundle that with the Hub by GoDaddy Pro to unlock more free benefits to manage multiple sites in one place, invoice clients, and get 30% off new purchases! Find out more at go.me/wpbuilds.

AND

The WP Builds Deals Page

It’s like Black Friday, but every day of the year! Searchable, filterable list of WordPress products, with exclusive pricing for WP Builds listeners!

Check out the deals now…

We thanks them for their support of WP Builds.

Transcript (if available)

These transcripts are created using software, so apologies if there are errors in them.

Read Full Transcript

[00:00:00] Nathan Wrigley: Welcome to the WP Builds podcast, bringing you the latest news from the worth rest community. Now welcome your hosts, David Waumsley and Nathan Wrigley.

Hello there and welcome to the WP Builds podcast. Once more, you have reached episode number 291 entitled the launch. It was published on Thursday, the 11th of August, 2022, my name's Nathan Wrigley. And before we get to the chats that I'm gonna have today with David Walmsley in our WordPress business boot camp series, first, a few very small bits of housekeeping.

if you like WP Builds, I would really appreciate it. If you had the time to go and review the podcast on your podcast, player of choice, possibly apple podcasts or Google podcasts, whichever podcast player allows you to review it, we would love to hear your thoughts and it. Does sincerely help the podcast to spread, which would be very favorable from my point of view.

So yes, just a little request from me. If you feel like doing that, I would be most grateful if you're in that category of enjoying the podcast, the best way to keep up to date with what we do is to head over to WP Builds.com/subscribe and subscribe to the newsletter there. That way you're gonna find out about the podcast that we release every Thursday.

That's what you're listening to now, but also the, this week in WordPress show, which we. Every single Monday, it's a live show where I'm joined on the screen by three, usually WordPress guests. And we talk about the WordPress news and it comes out as a podcast into your feed the very next morning. So that's WP Builds.com/subscribe.

You'll find our Twitter feed and our YouTube channel detail. I'm also promoting the WP Builds social channel. Now this is a free install of a piece of software called master Don. And really it's for those people who like talking about WordPress, but would rather not do it on a proprietary platform with something like Twitter and Facebook.

So this is data held on a server. It's just by me. The audience is pretty small at the moment, but if you're fancy signing up it's WPBuilds.social. Once more, that is a URL WPBuilds.social, go over there and sign up and keep the conversation going. And the last thing I want to mention is our deals page. I keep saying it's a bit like black Friday, but every single day of the week, WP Builds.com/deals, searchable, filterable deals, coupon codes, and there's loads there. And they never expire what a fun page that.

The WP Builds podcast is brought to you today by GoDaddy Pro. GoDaddy Pro the home of managed WordPress hosting, that includes free domain SSL and 24 7 support. Bundle that with The Hib by GoDaddy Pro to unlock more free benefits to manage multiple sites in one place, invoice clients and get 30% off new purchase. You can find out more by going to go.me/WPBuilds. That's go.me/WPBuilds. And we really do thank GoDaddy Pro for their continued support and helping keep the WP Builds podcast going.

Okay. We are on, like I said, episode number 291 of the podcast. This is the sixth episode in season three of the WP Builds business boot camp. It's the last one. Before we move on to series four and it's entitled the launch. It's all about that moment. When, if you are using the waterfall technique, like I am where you finally hand it over to the client, what are the things that you need to do?

What are the checks that you need to make, or if you're working. David with an agile approach. What are the things that you need to do to get this thing out? Just in its M MVP state? So there's lots to think about here. Most of it you've probably done before, but it's interesting to have it all in one podcast episode.

If you find that we've missed something out or indeed, if you think we got something wrong, head over to WP Builds.com. Search for episode number 2 9 1 291. And leave us a comment there. I hope that you enjoy the podcast.

[00:04:30] David Waumsley: Welcome to another in the business boot camp series, where we relearn everything we know about building WebPress sites and running a web design business from start to finish we're on episode six, which is the last of season three, which has been about looking at the technical build.

And today we are discussing the launch. Whatever that is Nathan and I are taking contrasting approaches to get our new business running. And our first client site built she's a lawyer with no previous site and Nathan as usual. So we just recap on where we're at.

[00:05:00] Nathan Wrigley: Yeah. Let's paint a bit of context. So the intention of this series is that we have alternative approaches mine.

Is the more typical approach, which I'm sure many people are using, which is to say waterfall. In other words, I go out to find clients, go and meet them, offer them a proposal, get some sort of contract signed and then go away, build the website with some collaboration, but largely alone, and then come back on a planned deadline and say, Here it is.

It's done. Let's launch it. So that's, that is literally the end of the road. In most cases, for me, barring things like care plans, but this is the moment in time where EV the rubber meets the road and it's all finished and done. .

[00:05:43] David Waumsley: Yep. And I'm going with an agile approach, which in theory, the launch is almost the start of the project.

So we're going for a minimal viable website that we get out. And then we constantly iterate on that and look at user behavior. The

[00:05:57] Nathan Wrigley: launch in my case is very much at the end of a long journey, loads and loads of things have happened from what you've just said in the future for you at least. Anyway, the launch is going to.

Really much further back in that journey. You'll have put things live when I'm still tinkering and building and doing all of the bits and pieces given all of the documents that I've been sent by the client.

[00:06:20] David Waumsley: Yeah we're getting something out as soon as we can and fail fast basically is the kind of approach to it all, learn from it, get the data, let the data design the website.

And, realistically we're talking about a small town lawyer or with. Probably thought of her as that way. So I'm not sure, so sure. How much of agile would actually come into a site like hers, but yeah, in theory, that's what I'd be doing. So do you know? I think it's really interesting. Should we just talk about maybe some of the problems that we got here?

Cause I don't. See other conversations at all about how you might go about launching websites, because we've got two types of projects that we might do as our kind of small agencies and freelancers. We've got the complete new project, like we've got with our lawyer where there's a new domain and we've got the redesigns where effectively we'd assume that the launch would be typical then because we'd be redesigning in a separate place to the domain.

And we wouldn't be concerned about getting traffic.

[00:07:24] Nathan Wrigley: Yeah, I think in this situation, because this client is new and they've never launched well, they've never launched this version of a website before. And we're purchasing a brand new domain it's never been seen before. There's no SEO to worry about.

All of that will build up over time. I think this is about as easy as it gets in terms of a launch. It's a small. Lawyer probably doesn't have great expectations, probably doesn't want to cause too much of a fuss or spend a lot of money with advertising and, making the world aware that the site is going to go live.

So this is fairly straightforward. This is really a phone call to say, it's live, go and check it out and make sure it's exactly what you expected and that all the links and the forms are being. So

[00:08:10] David Waumsley: with this client though, I might be able to convince her to go the agile route because it's a new domain and getting something out in some form or another would help her to, for the search engines to pick up one of the key issues.

I think for me is the fact that if you do this big launch on a new domain and there's nothing but a simple coming zoom page that doesn't. Google to know what it's about. Then you are waiting some months really, before it trust that domain is providing something useful to anyone. So I could convince her perhaps yeah.

To go Anja route. And we put in whatever we can, as we build it, as long as she isn't too particular. Our client about having this full blown website, which you do, everything is perfect, which you might be, cuz there's the other thing. It's client expectation here. I think, maybe some of them, they, if they're going to put out business cards for it or advertise that their offices are opening, which might be in her case.

She might on those cards, she'll probably want to put a website address and she'd probably rather have her come in soon page doing nothing that looked professional than a kind of half done website, which she's changing all the time. Yeah, that's a really

[00:09:19] Nathan Wrigley: good point. If you are producing materials, like real life stuff, like business cards and letterheads.

I suppose a conversation would need to be had about right. The website's clearly not ready. So should we just put something on there so that people know that it does exist and it will be coming soon? Yeah, I can totally see the point of that in. Did you ever do a big launch and what I mean by that?

I'm not really clear on, but did you ever do something which felt like it was a bit out of the ordinary where this moment in time was something a bit different? Because I don't honestly think I ever did the most that we ever did. Just announcing it in the local press or getting an interview, which never involved me, but the client would get onto the local radio station and announce the fact that they they had done this and, get some photographs taken to, to talk about it.

But that was as much as I ever did. So nothing ever felt really grand. For example, when apple launched their latest iPhone, you can guarantee that their website will be ready on the second. It's supposed to be ready. You can literally be watching their live presentation and refreshing the page and the iPhone is not available to buy.

And the second that Tim cook says, and it's priced at 899 billion from that exact moment, their website will be live and ready to go. But I've certainly never had anything like that.

[00:10:42] David Waumsley: Yeah, I've not either. And quite interestingly, there's. There's a project which I've done work for the same company, a number of times.

And each time, the time it's taken to get what they call a launch done has increased all the time. So recently it's been over three years and it's but even even though they've been talking all the times about launch and they've got a particular vision for what it is, and they don't want anyone to see it's.

Actually just slipped out there really yeah, I don't, I think in terms of then they're still probably not gone out there and told all people they know who might be interested, maybe, their. They a list or something. They might probably tell people on that, but so I don't think much is happening there, but it's interesting.

The only one, actually, the only thing I recall a proper launch is one we did for our own e-commerce site before I did this as a proper business, cuz that we actually did put that live and we actually had the party. Yeah. In the garden.

[00:11:43] Nathan Wrigley: So did that, that coincided with a whole load of other things happening in the business or was it literally the website.

Which, which was the cause of the party or was it that the business was firing up at that exact moment as well. And you. Yeah,

[00:11:58] David Waumsley: we had a party, it was a card shop. And we were putting them out in the cafe that we had these cards. So it was a sort of business that went with that, which my sister-in-law was doing.

And then the website was going live and it was only really just because we, it was an excuse to have a party, to be honest where there was lots of people we wanted to see so that was the only one that I would say, that actually felt like a launch, but it, but having said that really didn't.

Coincide when the site was actually effectively live

[00:12:29] Nathan Wrigley: on the web. Yeah the whole term launch in my experience, and obviously that's small town business experience. Is that really the correct term for that would be handover. There wasn't a lot going on. It was more a question of, okay, it's there, it's now yours.

It's ready to begin doing work launch sounds something going up into space on a rocket and it definitely was never anything like that. So much more low key, much more a question of, okay, this is what we've been building up to it's ready. And very often it was just done with a simple phone call or an email.

So like I say, it was about as low key as it could be.

[00:13:07] David Waumsley: And I've really thought about this recently, the whole launch thing, and what's expected because of trying to. Actually to this agile approach, just maybe think about things like the coming in soon page, because we're talking. I think both of us have never really thought about this.

All these years of building client sites and never really considered what're doing so I used to do it makes no sense now. I used to on a temporary domain. I would have a coming zoom page, which effectively would be set to tell search engines to go and index this nonsense coming zoom page, which did no good while I was building out the site, which then eventually would.

Turnover to the actual domain that there's a kind of, there was no logic to that at all.

[00:13:52] Nathan Wrigley: yeah. I suppose it depends upon what amount of information you put on that coming soon page. Yeah. So if it literally is, amazing website.com coming soon with countdown timer of, I don't know, three days or whatever, three weeks, three months, whatever, then that's really doing nothing other.

If people actually do go to that link, they see that something will happen. But if that page was, I don't know, some sort of landing page with some SEOable data on there. Yeah. Which might give a little tiny kickstart to Google, to have some indication of what's going on. I can see the benefit, but I never ever did it not once.

Did I use a coming soon page at all? I just didn't see the.

[00:14:38] David Waumsley: I did it just basically to hide what was happening on this temporary domain, which was telling search engines to go and take a look at this temporary domain. What was the point in that? Yeah so now , I think I'm gonna try and get something going if, as we, both of us decided in other chats that we like to work life on.

The actual life site rather than work locally, where possible we might as well make the benefit of that by trying to at least get a coming soon, which is on the domain that has some keywords in there at least. Yeah. So how,

[00:15:10] Nathan Wrigley: how would you, obviously in your agile approach that the whole thing is a movable feast and you're working on the live thing and every modification that you make with the client is going live at that exact moment, but how have you typically handled obfuscating the site whilst you work on it?

Have. Done it on, I dunno, a SubD domain and then just migrated it towards the end. Or have you just kept posts and pages in a draft state so that they were non discoverable? What has been your technique?

[00:15:39] David Waumsley: Here's the thing. I haven't had one and I'm still working it out at the moment. So recently, I think my approach now would be it I've moved to this agile slowly.

So last couple of clients that I've got, they've still got sites, which I'm pleased that out their life, because they wouldn't be, if we were trying to hold on to the things that they ideally wanted to get out there. Because, and it's still there. So I. Some hidden custom post types, which are just in drafts.

So they're not gonna get picked up on and we've got on another site, even on the pages, there are hidden sections of pages, which aren't showing on the site, but the site's out there and it can work live, but really, I think moving forward next time, I'd be much keen to make that coming soon page to have the process there.

So we get the copy in place. Talk about the fact that we can put that copy out and design live to the site because. Presumably, they won't be sending people purposely to that site. So with a new domain, it can pick up on some of that. And we just keep building around initially headless and footless homepage.

Yeah, because most of the homepages with the agile approach probably will stand alone as a landing page in effect anyway. Yeah. Everything that is needed to, make someone sign up. Perform a call to action should be there on that page. So that would be the aim now and then just to hide everything else and release everything else as needed.

But you're right. There's some technical issues about that. What's Google gonna crawl. If you use, say a site map or something, or you allow a site map to come out of. WordPress.

[00:17:19] Nathan Wrigley: Yeah. Typically for me, whether I was doing a brand new site or a rehash of a preexisting site, I would develop the whole thing on a SubD domain of my business website.

So it would be, I don't know, project X dot picture and word dot code UK or whatever it might be. That's the way I would do it. And the client would be given that. URL and they could go and log in and do whatever it is that they needed to do. Typically it was more a question of looking at the front end and making decisions about whether things were correct and whether they matched up to their expectations and then we'd get that finished and that the sign off would happen.

Over there on that sub domain. So right. That's exactly as we want it. And then it would be my job. The final thing would be to throw the switch, migrate it, update the DNS and put what I had over on my site elsewhere. And of course the. The no index would be switched on the SubD domain, which yeah.

We know where this is going mostly. Yeah. And then when you transfer it over, one of the, one of the SOP items was to make sure that the no indexing got switched to off on the life side. And of course, I know this is true for you as it is true for me, that actually got forgotten sometimes.

[00:18:38] David Waumsley: Yeah, so

[00:18:39] Nathan Wrigley: embarrassing.

Yeah. but yeah, as bad as it gets really

[00:18:43] David Waumsley: I think, that was always my big fear. There was a big, long list. And we'll talk about that later. What actually goes into a full launch, assuming the traditional model, I don't think it's any different from the agile. And now what I'm having to start to think about is how I'm, how some of these things are in.

Two, because if I'm gonna release something straight away, I've still got lots of considerations, even if I've just got a temporary homepage and it's usable page as my coming zoom page, I've still got all those legal requirements. I still need to make sure that it's, that site page is going to be accessible.

I probably need to have some privacy policy that goes along with that one page to stay legal there. Yeah. So I'm really having to think about the launch much earlier where previously it. Really big, long list of. Checkbox thing and thinking, have I done all of these things?

[00:19:37] Nathan Wrigley: Yeah. The thing about the way that I was doing it as well is that you really are bound by time.

And what typically turned to happen was that everything became very frenetic towards the end and all of these SOP items, have you got a well, privacy pages weren't. Really all that much of a thing, but, have I updated the DNS? Has the site migrated successfully? Have I called the client and got a response and all of this kind of stuff?

Yeah, it really does become very stressful. And if you haven't quite got to where you need to be the client knows that on the 1st of July, that's the date and anything outside of that is a failure. And it did, it ended up being quite a stressful thing. And I'm imagining that if I was.

Adopt your approach, the more agile approach that at least you would have less of that kind of stress.

[00:20:28] David Waumsley: I think it's nice. Certainly. Last couple of times, it's been nice to get their domain name to me from the beginning. Yep. That's made it a lot easier, cuz it's one less chore at the end that the that you haven't mentioned it so far, but you did, to me earlier about the fact, one of your issues would be with DNS is being with someone else and the difficulty you could have there.

[00:20:50] Nathan Wrigley: Yeah. I mean that, that was. On various occasions, that was an absolute nightmare in the I'd failed to figure out that the client's DNS was handled by some third party company. That third party company, may have gone on holiday or something like that. And so flicking the switch required me to send an email to them, which also had to be authorized by the client to say, yes, Nathan is allowed to change our DNS.

Please do whatever he says. And then sometimes, it would just. In an inbox for ages and never get dealt with. And yeah, so the launch date would come and go. It definitely wouldn't have been my fault per se, but it was my fault because I didn't make sure in advance that person knew what was going on.

[00:21:37] David Waumsley: Yeah. And I've had the, I dunno if it's the client just behaving that way, but they love to it's not my responsibility to get that over to my, because I'm hosting it. So they need to point their DNS to my server. To go live, but somebody else's controlling that. And then they make it a conversation between me and this other person who may have reasons to not want to let them go.

that's really true. Yep. Yeah. Or that, or they've got some issue about. Payments or something like that, and you get caught in this. So I'm very keen. Now, if you were doing it again, do you think you would not do the subdomain and try and get from the, a, the domain to your server?

It,

[00:22:22] Nathan Wrigley: it depends because if it was a, if it was an already live site, You don't really have much choice about that because you need that. Of course you need that business to be continually running. So now in some way, shape or form I think especially if I was moving a site that was not WordPress over to a WordPress site, then that would be, I'd have to develop it elsewhere.

In an ideal world, I would get a client who already use WordPress and. Probably start to fiddle with things over there, but no, I think I'd still be sticking with the SubD domain, but I definitely got better at figuring out the DNS problem earlier on. It never was right at the top. It never okay. Item number one is let's figure out who's controlling the DNS and make sure that I've got access to it. That it always ended up being late. So I would probably be better at that. .

[00:23:14] David Waumsley: Yeah. You know what? I've made a big assumption here, and this is key to the launch as well, particularly with the traditional model is I've already assumed here that because of the route I go, they always come to my server.

So it's logical, of course, that they, the first thing they're going to do is to point their domain, their new domain at my server. But if you're doing a traditional model you're probably going to have the conversation about the care plans and looking after the hosting of those sites, after the launch or just coming up to the launch really aren't you?

Yeah.

[00:23:46] Nathan Wrigley: That was the first thing, actually, to be honest with you, that conversation always happened fairly on and fairly early on what I mean by that is I would often try. To get them onto my hosting and care plan. And if that were the case and they were happy to do that, then that did make things easier.

Obviously the whole DNS thing still needs to be dealt with, but at least I knew where it was gonna be. And so I could build it on my infrastructure. And then obviously I was totally aware of how to migrate the site from here to there. But given that the clients often had a favored hosting company.

And, a C panel of some kind or a dashboard I would have to, in many cases, get to learn that as well, which was just another unnecessary job that I probably should have figured out earlier.

[00:24:35] David Waumsley: So our lawyer, if we were talking to her for the first time with either of our approaches, would we then probably at the beginning be saying that skipping that say, come on our hosting and we'll start you off and put the domain straight over to our hosting and we'll build your site, whether it's.

Hidden or not. Would that be our ideal approach with her? Do you

[00:24:56] Nathan Wrigley: mean their live current domain? If they've already got a website? No. You mean in this scenario? Oh yeah. In this scenario, if it's brand new and they were happy to go with, the hosting that I would be providing I, yeah, definitely.

I, I would want the details from the get go. And my expectation as well with this particular client would be that the words. Domain name servers and all of that would just be OTA nonsense to them. So they would be happy to be instructed in an email to send me the login details. I was always really surprised actually with how cavalier clients were with sending their emails and passwords to their hosting providers, just in a reply to an email, I'd be thinking, okay, how are we gonna get this password?

And immediately, okay. There, it all is in plain text and a password. That's in a sorry in an email. Fine. That makes it easier for me. I was always amazed. I've got complete control now over your domain. That's great. That always, yeah. That's that I think the best way. What about you? You're gonna be doing that from the get go aren't you?

[00:25:55] David Waumsley: Yeah. I mean that's gonna be my, I always want them on my server. It is tricky though. When they've got a live site elsewhere, of course you are building that on a temporary domain until they move over. That's definite there's nothing you can do about that with the agile. It's only on the new approach, but miss a.

It's easy for me to make. If I was a different agency earlier, then I would be building it separately because I would be thinking, okay, I'm building this thing, which they're buying off me, this product, this website, and it's my product. And, we haven't even had the conversation about who they're gonna host it with.

They've only come to me to build a site. The hosting is their thing as a business where nowadays I don't even entertain that. Yeah. That it's if I'm gonna work with you, it's just gonna be sensible to do it on our own servers. Yeah. Cause I'm, I'm gonna take more responsibility than previously I did for you.

I also

[00:26:48] Nathan Wrigley: feel that the whole migration thing is just so much more straightforward. Especially in the WordPress space. There are so many excellent tools, which you can really bank on that you can, within moments of you clicking a button. It really is. As simple as that, if you've got the login details, then you maybe a plugin, or it may be some sort of SAS service, like migrate guru or something like that.

, and it just seamlessly happens. But that was a, that was quite a big piece of the puzzle for me, getting. Getting a backup, putting it onto my local computer, then uploading it and unzipping it and making sure that the database credentials were all changed and that everything in the options table was correct.

Whereas now you just press a button and it does it all for you find and replace all done.

[00:27:40] David Waumsley: And another big thing that's changed with the DNS thing is that yeah, I was always very keen that clients owned and bought their own domain and had it registered with someone else. And they used to be able to just share their passwords and I could go in and do the fixes and point it to wherever it needed to be these days.

You can't. Now I have to organize a time because every time you log in to them, now it sends them an email to check in with you and you. Past number. So that is no longer an easy thing to do. So I having to reconsider how I might get involved. That the domain names themselves.

[00:28:17] Nathan Wrigley: The, I think this, may, maybe I'm wrong.

Maybe there is an actual reserve, a pot of money to be made about handling the registration of the domain. But for me, I think now they're everybody knows how to buy domains. They can do that themselves, but you're right. If you do need to make a change and they've got two factor Orca authentication switched on and it, yeah.

It's not something that you could have put onto your phone if it's sending them a text message or an email that is another impediment, isn't it? That is a bit of a, that's a bit of a thing, but I think it's, I think ultimately. I came down on the side that the clients owning their own domain and running their own domain and purchasing it every year.

And it being on them was probably a better idea. I tried both and I've still got quite a few domains that every year I have to pay for and then invoice clients for. But ultimately I, it's such a trivial amount of money. It seems it's better off. Just let them do it. And then if something goes wrong, it's on them and not on.

[00:29:16] David Waumsley: Exactly. And then things tools like better up time to send you a nice little warning is that it's, a couple of weeks. So if you think you've got a client who might forget this, you can set, be on the ball and tell 'em that I, one of, one of the site I was talking to you earlier about this, one of the other benefits of them buying their own domain names from their preferred place is that you end up with different Domain name servers that you are supporting, if you are running in their main server and some of them go down and when they all go down, all of those sites on that domain name server go down.

So if I took care of that and put them all with the one supplier, then all their sites are gonna go down. Yeah. And I can't distance myself between their uptime and what I'm providing, where recently I've been able to say, Hey, you guys are all on. Domain name supplier, and you've just been going down recently, servers up here.

Other people are fine, but just to let you know, and if it's a problem, I'll let you know again. So it's nice to be able to separate my, what I'm offering away from what the DNSS are doing.

[00:30:22] Nathan Wrigley: So you've had that as a problem that one of the, one of the registrars that their domain name servers have gone down.

And so it's just not feeding traffic to the. For any of their customers. Oh, okay. That's a,

[00:30:34] David Waumsley: yeah. Recently, two. A couple of days apart, we had two half hour to 40 minute sprints with one domain. So seven sites that are with those all went down on my servers where all the other sites are up and, the better uptime tells me it's a DNS issue.

And. It's quite nice being able to separate my kind of hosting uptime different from the domain name server. Whereas if I was to do that for everybody and put them on the same one, they're all gonna be down. I'm not gonna be able to distance myself any longer. Yeah.

[00:31:09] Nathan Wrigley: So I suppose if you've got one that you rely on and it goes down, that's a tragedy, it feels that's quite a rare thing though.

That never really bit me. I don't think. Yeah. Up until fairly recently, I was using Google. Google domains as the registrar. And they had a, they have a nice feature in there where you can delegate the account. So your clients so long as they've got a Google account, which most people do, they can log in and make amendments themselves.

But also they can take ownership of it. So one of the options, which I think is really nice is that the client let's say the scenario where I'm hit by a boss. The and I've actually had that in not me being hit by a boss, but the, one of the, the other way around, one of my, one of the clients came to me and said, look, My web developer who bought and paid for the DNS has passed away.

What can we do about it? And the answer was not a lot apart from go through some sort of convoluted I can process, but with this Google domain setup that the client could just log in and say, actually, it's mine. Now give it to me and lock Nathan out. And I think that's quite a nice feature. I've no idea how that works or how it's implemented.

I've just seen that it. But but I've moved everything now to CloudFlare pretty much. Everything's basically over on the CloudFlare side because I see that as a pretty solid solution and it's not let me down yet.

[00:32:41] David Waumsley: Yeah. Thinking about it, my extra benefit, isn't really an extra benefit. It just needs to make sure that we're good with good DNS provider,

[00:32:49] Nathan Wrigley: right?

Yeah, really. Yeah. Yeah. And honestly if it's going down twice in a couple of weeks, some questions need to be asked about that. Don't they? Cuz that's one of the few things they've gotta really get. And if they don't get that right and their servers are going down, that's a bit catastrophic.

You imagine how many customers they got phoning them up during tho those half hour

[00:33:09] David Waumsley: periods. Yeah. I get caught quite a lot and it does go across multiple suppliers. It. Huge. They're still running at 99 point something percent uptime. Yeah. Yeah. On average, I'm just, when a few go down more often than others you spot it.

That's all, but you're probably right. If you go through cloud fair and I have got one, I was saying to you, that is with Google. They've registered, but I'm not sure if it's entirely connected up, as you were mentioning before, they've got they've got options. Haven't they

[00:33:43] Nathan Wrigley: for? Yeah, I think it's five, five points of failure, I think.

Yeah.

[00:33:47] David Waumsley: I suspect we're not set up correctly for that. So I have noticed that go down before, but anyway, we're onto a different topic. Should we talk a bit about what we need to do before we can launch? Yeah, let's go for it. Okay. These are different categories here. There's you could, I saw a list.

I think it was something like 80 things you need to do. There's various items, I think on the

[00:34:10] Nathan Wrigley: where's item one, ignore the remaining 79. Yeah. 80 it's that is that really? 80 opens. Good

[00:34:20] David Waumsley: old. Yeah. I've seen a load of 'em. So I think there's a competition out there. More things on your checklist, but basically I think they fall into basic categories of, so I'll just run through this quickly, shall ive listed.

So we've got security and backup. We need to set up, we've got some form of analytics, perhaps that's numbers or user behavior, SEO, legal accessibility, privacy, copy. Make sure that. Spellings correct. And stuff like that performance, which could be speed testing and also setting up the site to be fast browser and device, so responsive stuff and making sure it works on all devices and functionality, things like contact forms, email signs up, and you've put in on the end, the DNS as well on this one, too.

Make sure that's all kind of set up properly.

[00:35:07] Nathan Wrigley: Yeah. I guess in your process, all of this is just hap well, there's a couple there that like setting up the backups. Maybe you wouldn't have set that up, but things like the copy and the responsive stuff and making sure that the contact forms work, all of that's probably gonna have been happening along the road anyway, but I would encourage the clients to go and basically.

Poel the site for, visit every link that you can find, check that everything's in the right place, go to this page, submit this form, make sure that you get it, you get an email and so on and so forth. Yeah. But a lot, most of that would've happened. And really all that I'm doing is checking that the migration.

Occurred correctly and that nothing got weirded out on during the migration, cuz I would've done all of that stuff apart from the DD indexing, the SEO bit, hopefully all of that would've been done several days before we finally get to this moment in time.

[00:36:06] David Waumsley: Yeah. I quite like the fact that these things are done slowly over time.

Just things like forms, you it used to feel like a real chore. When a site went live, just going through all of these things and checking them out. I dunno, but now it feels a little bit better now I'm slowly releasing bits and pieces,

[00:36:27] Nathan Wrigley: but also, if it was a big site with like hundreds of pages and so on, I think I really wouldn't be checking everything.

I'd probably just be checking some headline pages, the things that are in the main navigations and checking a few random links and making sure that they all work. But if it's a site, so I don't know a site with User inputted data. So it might be, I don't know, a product listing or a real estate site or something like that.

I think I probably wanna be a bit more thorough. And on the new site, I'd probably wanna put up a few fake listings just to see that it's all working and quickly delete them, just to make sure that those, I don't know, ACF fields are actually mapping to where they should be in the templates. And.

[00:37:07] David Waumsley: Which is what you just said is quite interesting there about the fact that there's, one thing that we now start to expect from websites is that they've got some kind of social proof and on a new domain, you're not even gonna be able to have that kind of section of your site complete before you launch really, unless you make up stuff.

Yeah. yeah. It's a point for agile. The other

[00:37:30] Nathan Wrigley: way. Yeah. Yeah. Either that, or you just have fake social proof, get your mother to write something and , that's always gonna happen. But yeah, that list looks pretty solid to me. Security, backups, analytics, SEO, legal copy, performance browser functionality, DNS.

Yeah. It's not 80 points long, but that covers most things.

[00:37:52] David Waumsley: yeah, within that, I'm sure you could go over 80, yeah. For actual hands on jobs to do, but there are some other things that I guess are gonna come into it. The other thing is gonna be perhaps client training, which we'll talk about in the next series.

Ah, yeah. Client

[00:38:08] Nathan Wrigley: training, good point. And how we hand over. Yeah. Yeah. Typically I would do the client training after it's actually gone live. That just always seemed like the best time to. It because then at least it's what it is. Whereas I always felt, and your agile approach is entirely the opposite.

I always felt that if I allowed them to have the training before it was live, they might want to make amendments at that point, oh, okay. Does it work like this? Can we make it so that it behaves like this? Instead? I'd rather this was here. Whereas if it's live and it's all been paid for and the contracts, it's all been fulfilled at least now it's look, this is what it is.

This is what you agreed to. We've been. This is it, yeah.

[00:38:50] David Waumsley: But that's a tricky thing, isn't it? Yeah. Cause if the, I always feel that it was certainly true in my case when I was working with somebody else, the client training side of it, and it's still poor, isn't really factored into the build of it.

Most of it, the focus is on getting this website out or was before for me. Yep. And the client training is this few hours. After thought

[00:39:12] Nathan Wrigley: really? That's right. That's totally true. And in my case it was mostly reactive. It wasn't like I've got this suite of things to say it was more when the client, you've been here, I'm sure you've been here.

The client you go through with them on a certain day, what it is that they've got to do. And then a month later, they phone you up and say, how do you log in? How do you do that? How is it that I amend this thing? I've completely forgotten because they weren't paying attention and they were just sitting next to you and nodding.

And so for me, it was often just reactive and it was a question of making tiny little, short, 32nd videos in response to a problem that came my way. The whole, how do you log in? Okay. Let's make a quick video. Here's the URL. Watch this video. And put it somewhere. Yeah. Put this video somewhere safe, just stick it on your desktop or something.

And then next time you do it, you can refer to the video. And then by the third time you won't need the video anymore. Cuz it'll be part of your muscle memory. We'll

[00:40:10] David Waumsley: have lots to talk about for next season on that. Yeah. So the other thing one thing that you added to the list here of other things just suddenly made launches more exciting to me, penetration tests.

Ooh. Let's talk about what that is. Yeah.

[00:40:23] Nathan Wrigley: So I, I never did this, but I did have clients who had. Fairly technical staff, that they were in technical industries. It was the one I'm thinking of it was in the car industry. And they obviously had a lot of technical people cuz they were working with computers and CAD and all of that kind of stuff.

And one of the guys said, I'm gonna run a penetration test on the site. This was after it had gone live just to see how everything is. And honestly at that point, part of me wanted to die a little bit on the inside because I didn't really know what was about to happen. Pure luck would have it, nothing came back as a problem, but they flooded the website and it was actually on their own server.

So it was literally on a box that they owned. So part of it was, we're gonna swamp the site with visitors and the server stood up to that. So that was on them anyway, so that was good, but they also tried to inject malicious things into all the forms and luckily the sanitization process. That the forms had made that a non-pro.

So I was very lucky in that it came back with a complete clean bill of health, but I don't honestly know. I think at that point, my technical expertise would've been really in question because all I would've been doing is saying, look, we agreed on this form plugin. We agreed on this way of doing the site with this CMS.

I dunno what to say at this point, but I didn't have to deal with it, but yeah, there's another thing to think.

[00:41:51] David Waumsley: Yeah. So that's really stress testing plus . Yeah. Cause I've done a bit of stress testing, but really for my own, really, for my own sites, most of the time, the eCommerce one, I wanted to know when I moved to.

Hosting, whether it could deal with so many clients on an e-commerce site at the same time. So I did a little bit of that, but I've never really needed to do it with mine, but I think it's a, it's another thing that might be on the list before you launch to know that your hosting is going to actually deal with that number of concurrent users, particularly if you were doing something like.

Training stuff for courses or something like that where people needed to be logged

[00:42:31] Nathan Wrigley: in. I guess also in this particular case, the fact that the server was a box that they owned and it was in their building. So they'd figured out all the routing of that and the DNS and everything. I'm guessing that they wanted to be absolutely sure.

That they weren't opening up some sort of backdoor into their own network. I can't be sure about that, but the guy was clearly very technical. He didn't understand anything about WordPress. He didn't need to, he just needed to know that, okay. If I throw this at it, what's the outcome.

And luckily there was no problem. I would've been in, in a bit of Dodo if if I'd have had a problem. I think I wouldn't have been able to speak the same language that he was.

[00:43:16] David Waumsley: yeah, that, and then another angle, which I guess I've never really been involved in is the fact that you might have to link the promotion of the launch up with other online stuff.

So perhaps Google, Facebook ads and social media teases that might need to go out. Yep.

[00:43:34] Nathan Wrigley: Yeah. This, again, for me just being small time. That stuff never really happened. It really wasn't a big deal, but if you're in a big agency and you're launching a big product for a big company, the coordination of this would be massive.

Everything's got to happen on that moment. And so even with your agile approach, there's gonna be a moment in time where look, David, we have to have it done by this state, please. And it's got to be at least this so that we can get the get the socials going and spend thousands and thousands of pounds on Facebook ads.

[00:44:08] David Waumsley: I know only if it was that way round, it's usually the other way round where I'm quite keen. Yeah. yeah. Yeah, so yeah, I think probably, I think we're done. We've done all because yeah. We're yeah, we're just leading on next series. So we'll just talk about all things related to the kind of training clients we'll look at their trading needs and their limitations.

What kind of website documentation, if any, we. and the support we provide, how we'll be dealing with changing staff. That's oh, that's a big one for me.

[00:44:41] Nathan Wrigley: For new management. I think for season four, you're on your own because now that we've launched the website, I'm done, maybe you've gone. I'm gone. I've cleared off.

You've got I'm now going back to season one and starting again.

[00:44:53] David Waumsley: Yes. It just joined me

[00:44:54] Nathan Wrigley: training. Yeah. Yeah, so anyway, that was really interesting. The website's launched at last miss a hopefully, yeah. Is dancing around, showing all of her friends and neighbors, her beautiful new website and everybody's happy and the rainbow is out, but yeah, we'll see how long that lasts.

So I'll see you in a couple of weeks.

[00:45:13] David Waumsley: Yeah, bye bye.

[00:45:15] Nathan Wrigley: I hope that you enjoyed the podcast. Always a pleasure chatting to David. This was an interesting episode where our paths diverted him using agile is going to get something launched much more quickly than me, where I go for the waterfall approach and try to do everything before thes.

Site is finally launched, but there's lots and lots of little steps that we learned about today. We hope that you enjoyed the podcast. If we missed anything out, or if you've got some commentary about it, head over to WP Builds.com and search for episode number 291. And leave as a comment there.

The WP Builds podcast was brought to you today by GoDaddy Pro. GoDaddy Pro, the home of managed WordPress hosting, that includes free domain SSL and 24 7 support. Bundle that with The Hub by GoDaddy pro to unlock more free benefits to manage multiple sites in one place, invoice clients and get 30% off new purchases. Find out more by going to go.me/wpbuilds. We really thank GoDaddy Pro for their continued support of the WP Builds podcast.

Righty, ho we will be back next week for a podcast episode. Hopefully we'll see you around somewhere perhaps on Twitter, perhaps in Facebook that we ought a Facebook group. WP Builds.com/facebook. Join us there as well. If we don't see. I hope you have a nice week. Stay safe. Cheesy music is about to fade in byebye for now.

RECOMMENDED STUFF

These are affiliate links and the small amount of income we derive from affiliate income allows us to pay the bills and keep the lights on