How To Start A New Project

So today, we're talking about starting brand new projects. Yeah. You know, you've obviously got projects on the go quite often. I don't start brand new projects very often, but I just don't happen to be in early talks about one at the moment, just a little, free launch project.

So quite fitting topic for today. So I just want to sort of pick your brains on how you go about starting a project from the design process, picking out your tools, how you organize yourself, how you go about coding, how you go about testing, releasing and sporting, and just the whole journey really. So, I mean, a little bit about this project that I'm about to embark on. It's just early stages.

It's just a marketing landing page. But, you know, because it's a new project that I'm, it will, because I haven't started a new brand new project in a while, I'm having to think to myself now, what should I do? Should I just create a static HTML page? Should I pick out something like WordPress or go for a, like a static site generator or, you know, even reach for a framework or a boilerplate or something like that?

Because if, right now, it's just a landing page, single page, but it could then evolve into a full-blown website, and then, you then start again, or you just build on what you've already built. So, yeah, I'm, it's going to be a bit of a learning thing for me, just to see what your process is really. So, yeah, maybe if you want to just kick us off and let us know, how do you go about starting a new project when you get a new client off? Yeah, sure.

So, when we take on a new client, it's, it's a case of, you know, first having the conversation with them, discussing the requirements, what they're going to need. Jilly, just from scratch, there's nothing there already, so there's no existing website. We literally start everything for the rest of our research. You know, we do compared to the research with the existing sites out there, in the same sort of space, just to get an idea of what's already out there, who's doing what, look and feel, features, functionality, etc.

And discuss with the client, you know, what they're going to need. Yeah, so, in terms of, especially functionality-wise, what's going to be required, what's the site going to do? And once we've got an idea of that, you know, we just go through the very sort of like initial stages of building like a sitemap, so just understanding the structure of the pages that are going to exist on this website, along with very basic wireframes. Yeah, so very, very simple kind of layouts of how certain pages are going to look.

And we don't design, we don't wireframe the whole site, so we don't go through and do every single page. We'll do like the home page, because the home page is very distinctive, right? It's going to be different to all the other pages. And then we'll do a content page, which will probably be used again and again for other similar pages, right?

And maybe a variation of the content page, just showing how it can vary with, say, maybe text on the left, image on the right, grids in there, things like that. And I use starting a paper while you're getting straight into something. Yeah, so we use a tool, so, you know, it'll be done in Figma, which we've mentioned before. There is another tool that we come across recently.

It's like a collaborative tool, which like Figma, but it's a bit more lo-fi. It's a bit more like broken down and bare bones. And it's purely like, you know, you can use a drawing tablet and just sketch stuff out, and the client can see you're doing it in real time. So you can have like a zoom call, like we're having a video call now, and then you can just do it in real time.

So we use that sometimes. But yeah, otherwise it's done in Figma. And we're sort of really basic using shapes and blocks and things like that. And just kind of highlighting where things are going to appear.

So we have menu goes, where images go, where text goes, etc. Yeah, all that kind of stuff, just to give the client an idea of how things are going to look and how they'll be displayed. And we'll do it across mobile and desktop, just to give them an idea. Because a lot of the time these clients just want to see what it's like on desktop.

They just don't consider the mobile view. And for where these days, it's very important that your mobile view is actually user-friendly, fast loading, and you know, it serves its purpose on mobile properly. Because I think it was fun, I think for most projects it's probably, you know, the preferred. Oh yeah, definitely.

I think more so now. What happens is when clients come on board, they just don't, it's not important for them. So we've got to really push that and kind of say to them, look, you know, just to get about how it looks on desktop. We really got to worry about how it looks on mobile because that's the experience that, you know, Google is essentially looking at that experience, right?

So when you're running your ad campaigns, etc., it's really looking at your mobile. And the recent algorithm update from Google has basically said that mobile is now being indexed before desktop. You've got to think about how people are going to get to your page as well. If they're going to be clicking on ad and Facebook, most likely that ad is going to be kicked in the Facebook mobile app.

Exactly. So then it will launch the mobile website, for example. Yeah, so we push that on the Y-frame. So mobile first, we do the desktop as well.

And that's generally like the very initial stages of how we start the project, the Y-frame side of things. And then once the client's kind of happy with how everything's looking, where things are going to be, you know, obviously they're going to have their thoughts and opinions about some of these things. And they'll take on board. But once that's done, they're going to start fleshing out like a high res design, pixels or perfect kind of look and feel with color, stock images in there.

If they already have some text available for us, we'll start putting that in at that stage. And you know, give them an idea of what an actual website will look like once it's and the cool thing about Figma is you can start prototyping within the design phase as well. So while you're designing it all up, you can start connecting buttons and links to pages and create your animations and things and all that kind of stuff. So it's pretty handy doing all of that at the same time.

And then we can share it with the client and they can kind of review the design in real time. We can add notes in there to kind of explain our thinking behind certain things. So you know, the hamburger menu, you know, what it does, what you're going to expect from it when you tap on it on your mobile device, is the menu going to drop down? Is it going to push in?

Is it going to slide in? Little things like that. The thought process behind these things, you know, because a lot of the time, if like, we'll ask, oh, are we going to have any kind of like cool bells and whistles? So are things going to fade in as you scroll down and you can't actually show that in a prototype with Figma?

So we kind of annotate that to explain that, you know, you can have this here that could appear over here, little things like that. It's a sticky menu. We can't really do that in Figma, but we can annotate it and say, yeah, this will be a sticky menu basically. Yeah.

So, yeah, that's all the design sort of phase done there, prototyping done at the same time. And in some cases, I'm just referring back to my notes. In some cases, you know, we will design in the browser. This time is where, just to give you an example, if it's not a full blown web project, if it's like a landing page, we, what we will do is we'll wire frame it in Figma.

And then instead of going for the whole design process, we'll just build it up in the browser story because the chances are we're working on a website that's already there and then the landing page is an additional page to the existing site. And we'll just go into say WordPress and start building out a new template, whether that's from scratch or using a page builder. This is a really cool, powerful page builder out there now, which you can use to generate landing pages. Elemental being one of them and they've got a new feature as part of their recent update, which is a landing page feature.

So you can actually define a page as a landing page. And so it's completely unique from your content pages and posts on WordPress. So, yeah, pretty handy. So yeah, we'll do, we'll design in the browser when it comes to the landing pages like that.

Yeah. Yeah. That's kind of the camp that I'm from as well because, yeah, like I said, I don't work on a lot of new projects very often, but little side projects of my own personal things. I tend to start with a bit of sketching on paper first just to get some high level layout and positioning in my head.

I don't really go too deep paper. And then from there, I tend to go like you go to Figmores or, and then start working on Y framing. I don't spend too long on paper. And I generally don't really show my paper sketches to the client unless they really admin on seeing it.

It's more just for me to do a brain dump. But when I'm working on little side projects for myself, like my own personal website or you know, when I did a redesign of the inspect website, yeah, just to the straighten the browser, just find up a local instance and just basically delete the CSS and start again or something like that. Yeah. Being a front end developer, that's, I feel a bit more comfortable there making little tweaks there than pushing pixels around in Figmores just trying to get things looking perfect.

Because then you just don't know how to put it into the browser. You're gonna have to make little changes here anyway. Yeah. Yeah.

Right. Because it's, it's firstly time consuming to design for all the different screen sizes and responsive screens in your design tool. Whereas if you can get straight into the code, then you can see it in real time how it responds to different browser sizes and different devices. Exactly.

Which is always a bonus. Yeah. And then so you mentioned Webpress a couple of times, you're building most of your stuff in Webpress site. Yeah.

Most websites, content-based websites are, we're building in Webpress. There's other tools out there that we use, but they'll be for e-commerce projects, so Shopify being one of them. We started using big commerce recently. And yeah, it's pretty cool.

They've basically launched a similar product to Shopify. Because Bcommerce was this like enterprise level platform. And now they've done a competitor for Shopify, basically Shopify is like a basic level suite. So yeah, it's generally Webpress we use.

And yeah, and everything that comes with that. So we'll have like a set of plugins which are essential for us to get the build done and to make sure that we can work with Webpress with where it is. We don't blow them. I've seen a lot of people, I've had access to websites where somebody else has built it and there's like 50 to 60 plugins in there.

Just to add in the ability to create CSS files and create custom CSS files, I'm like, why would you want to do that with a plugin? And so what we will do is we'll keep it minimum. So things like if you're going to do page caching, GZIP, things like that, to optimize the speed and that kind of stuff. So we'll use plugins to do that, back up plugins to help work with our backup that software we're using.

Maybe we'll use, like a cloud, what's it called? What's it called? It's called Cloudflare and I think Mac CDM is just our stack path. So we'll use like the APIs for those and maybe we'll use a plugin to optimize the images on the site as well.

So the new format, WebP, that kind of stuff. So I guess it's about six to seven plugins out there, essential to make sure the website's fast and optimize, et cetera. Even for on page SEO. So I don't know if you remember that when you were using WordPress.

So powerful piece of kit, that one. It just makes it easier for, we've got an SEO person on board right now, our intern who manages that. So it's a case of going in there, putting in your key words, your focus key words and optimizing each page. And it's really handy.

So the essential ones we go with. Something like Yoast is worth investing in though, because the job it does is quite fast, isn't it? So you're trying to set up all that SEO across all of your templates and your pages and your posts manually. It's just going to be like that.

Whereas some of these smaller plugins that you can get hold of, like you said, to add a CSS or to add social network links and your foot in things like that. Obviously, they're there for a reason. Me and you web developers, so we know how to dig in and get into the backend and start tinkering. But a lot of the WordPress users out there are not code savvy and they need that visual editing experience.

So plugins do help them, but yeah, you're definitely right. It does get bloated pretty quick. I haven't done a big WordPress site in a long time. The last one was like a furniture company that I did about seven, eight years ago.

And yeah, try to keep it fairly minimal. But as client requirements increase, then it just becomes like, okay, we need to make the editing experience correct for the client. So we need to install this plugin to allow them to make this change. So you've got to think about your client and in this process as well, what is it like for them?

But I mean, for me, my setup is pretty different because a lot of the sites I build are blogs or small brochures sites, a couple of pages here and there, maybe a little bit of JavaScript on them, maybe a form in bed or something like that. So nothing too complex. And I tend to reach for static site generators. I've used quite a few.

I've used Jekyll in the past. I've used Gatsby, which runs on React. More recently, you've been using one called Eleventy, which is a JavaScript based one. And it's really good.

It's fast. It outputs just like HTML, CSS and minimal amount of JavaScript, depending on what you obviously do. And then you can just basically host that wherever you want, right? Because it's just static files.

And then in my development process, I'll have a few like MPM packages which help me do certain things. I'll have my SAS processing, I'll have my image optimization all done, it's part of my build process, so that the final output is just a optimized, clean, static HTML, CSS JavaScript website, which can then just stick on Netlify or just FTP to whichever hosting account you want. Yeah. Yeah, Eleventy's really good.

I mean, doing that one. I had my own personal site previously, but it was just getting a bit too much. Having a simple site like that go and react. I found that I was having to jump through a lot of hoops just to get it to do what I wanted to do.

And it didn't really need that overhead of having React running in the browser. If for any reason that doesn't load, then your site doesn't load, right? Whereas with the static site, like it is now my own personal website. There's no risk of it ever not loading unless something goes terribly wrong, but generally it doesn't.

So yeah, I tend to reach for those. At work, we use Angular. So any sort of new projects that we do at work, we're reaching for Angular's every work, previous jobs I've worked in React. And then generally just vanilla JS, really.

We don't really reach for anything else these days. jQuery is pretty much out of the window. We're sort of phasing it out in a lot of areas. I think we've still got jQuery in some of our projects at work and outside of work as well.

But just always looking for ways to phase that out and just make that whole development process as lean as possible, the whole build pipeline. Like you said, we're plugging in, just trying not to rely on too many third party frameworks, plug-ins, libraries and so on. Just another overhead. I think the JavaScript side of things.

When we use a theme, there's this whole school of thought with web developers saying you should rely on a theme or you shouldn't use themes and build the whole thing from scratch and create your own theme, which is great if you've got the time to do it. Brilliant. That's a really good way of building with WordPress, not relying on third party or off-the-shelf themes. But time is an issue.

And we're working on loads of different projects in currently. And we need a workflow that's streamlined enough for us to get stuff done quickly. So we've got two themes that we've tried and tested and they are about as vanilla as you could get. And they've literally got the things we really need to have access to.

So for example, being able to edit your header in WordPress, usually you don't really have access to that. You can change your logo and change your menu. And that's about it. We use a theme called NEEV and it's got the customizer is really powerful with that.

And it allows you to go in there and actually modify the header and drop in additional HTML elements if you wanted to. You can put a phone number in there. You can put a tab to call with a little feature in there. You can split the header up into three rows if you wanted to.

It's just really powerful. So we wanted that kind of feature because it helps you to set different headers and menus for different landing pages. So you can actually remove the header and menu from a certain landing page just by using that tool. It's pretty handy.

So it just makes our life easier. And then what we will do is off that theme or create a child theme, which you probably know about the reason behind that. So that's all our customisation takes place in the child theme. So we'll use our own functions.php file and we'll just create our own custom functions in there.

Do you want to just quickly explain what a child theme is? Because people don't know. Yeah, so when you get a theme, it's generally kind of includes styling, the layout for pages and all that kind of stuff. And the general looking feel and you can change that in the options within that theme.

But what happens is once you've got a theme set up on your website, the theme developers at some point will release an update with that theme. And the idea is you just kind of hit update and then it will just update everything. Now, if you're going to customise that theme, which is what we do, we customise the hell out of it. We work with our own PHP templates for certain pages, etc.

So we do a lot of that customisation. And when you do that, you need to do it in a child theme basically. And what that allows you to do is there's any updates for that theme in the future. You're not kind of interfering with the child theme.

So you can update the theme and because you've got a child theme there, it won't affect any of the changes you've done. So it won't overwrite them or break your sort of thing. So it was a similar concept to like version of a child. So you've got to work on a new feature of something you branch off and then if someone else in your team happens to push their work into master branch, it doesn't affect you.

It's handy. It's a basic concept. Yeah, it's really handy. I've noticed a lot of people, when we've looked at websites and built other people, notice there's no child theme in there.

And it's like, oh, God, they've made so many changes. They've actually gone in there and made changes to the HTML, CSS, things like that. When was child themes introduced into WebRIS? I don't know.

It's pretty old. It's been around for a while. Yeah. Yeah, but there's loads of themes that will end the marketplace so they don't have the ability to have a child.

Have a child theme for anything that's out there already? This is the thing. And then things got to be done according to WordPress's sort of like format. So there's a certain way it's got to be done.

And as long as it's not just the case, I'm just adding a child theme with the same name. Not at all. Because we've tried that in the past. Like we've used this really popular child theme generator.

It's a plugin. And what it will do is it will basically check your existing theme to see it's compatible with the ability to create a child theme. And it allows you to basically you type in the name, the new theme, the author, et cetera, and then you can kind of define your CSS, your JS files and all that. You can really drill down in there and kind of organize your child theme, fully customize it and then hit generate and it will just create it for you.

And then it's the case of working off that. Now I've worked with that a few times where there's been a scenario client built their website themselves and they've got to a stage where they want to kind of say, okay, look, you can go recreate it, build it from scratch, et cetera. But they're happy with the theme they're using. Right?

Because it's got all the bills and whistles that they want. But what we will try and do is create a child theme off the back of it using that generator plugin. But then it throws up an error saying that the theme's not compatible and it's not going to work. And that's when you get, okay, it's not going to work like that.

Maybe we can try manually. So you'll go into your FTP folders and just create your child folder, et cetera. And then you've got to kind of mess around there to try and get it all working. So things like calling a CSS files, like the theme will be using the old format or including a CSS file, which isn't recommended by WordPress anymore.

So there's things like that that you need to kind of get around. But I guess nine times out of ten, the themes that are out there are well supported. So they'll just work out of the box when you are creating a child theme. Yeah.

So you've essentially got these couple of themes that you used to customize all your projects. So you've got these level of play. That's it. And we just reuse them.

Yeah. Because all the paste templates already and we just reuse it again and again and again. Yeah. And I think that's totally fine.

You know, even in your line of work where you're, where you are obviously charging clients for work, I wouldn't ever consider that as taking any short cut because, you know, one of my previous jobs I worked for IBM and IBM's not small, small little design shop is it. And we worked in the same way, we had a boilerplate. And everything on one of our projects started from this boilerplate project. All right.

The boilerplate was pretty big. You know, it was a Java back end with a Adobe experience manager for an end on it. So it's pretty big. But it had loads of custom components that we had created over the years.

It had all of our custom functions and CSS and just everything, you know, integrated with our backend APIs, integrated with our third party software and with our other middleware and stuff like that. So why would you then go and rewrite that every single time? Exactly. Yeah.

That's like saying I'm not going to use jQuery because I'm going to write all of my JavaScript from scratch every single time, of course you're not. So yeah, if you've got a good theme and you can customize it enough to, you know, give yourself a lot of unique options then by all means go for it. So it's a good thing to have. Yeah, I think so.

And it really helps with our workflow. You know, we're able to just get stuff done really quickly. We don't need to have to go in there and look for stuff. How do I do this?

How do we get that working? We know the themes we're using inside out. I mean, not exactly where all the options are to get these things sort of like working. But then the rest of it is all literally done through the functions.php file, which is like, you know, a godsend in WordPress.

So we overwrite existing functions and stuff. So especially with WooCommerce, we're able to kind of overwrite a lot of stuff in there and customize the whole checkout process. It's an e-commerce site. Very powerful.

And the same is with Stack- So they'll have a start template for a blog for a podcast, you know, for a basic e-commerce site, whatever, you know. And then they'll have various different styles in the design. You might have a minimal blog. And that's very, like, photo-focused photographers.

You might have something that's got an audio player embedded into it and stuff like that. And, you know, they're there for a reason. They're there to get you started as quick as possible. And then they give you, you know, the tools that you need to customize.

My own personal website, pretty simple. But I started with a template as well. I found some like an 11T template on GitHub, which is really nice. It had a lot of SEO built in.

It had like SVG icon handling in there. It had like its own development server built in. It had a good build process. It had SaaS built in.

So all these things were already wired up, which saved me, probably saved me a day's weather work, right? All I did was I installed the template into my local repository, deleted the CSS file, and then started hacking away the templates. And off you go, it's basically starting from scratch, isn't it? Yeah, that's it.

You know, what we'll do is we'll start building our own templates to kind of fit in with the child theme. And that's the real fun bit, you know, when you open up the code and you start writing HTML, because that's the part where when you're working with themes, you kind of like don't do a lot of that writing code. There's not a lot of that going on. But when you're creating your own landing pages and custom headers and, for example, custom post types and your own fields and things like creating really, really custom content.

For example, there's a site we're doing for hiring villas or villa hire in Marrakesh. And a lot of that I've wrote from scratch using custom post types. So I'm not using any third party plug-ins to create a property and manage it, et cetera. So it's all done by clickable button.

It's literally custom post types. I've created a custom post I call villas. You go create new villa. You can add in the name of the villa, the location, work in the Google location for it.

And it slits out page with your gallery, a nice background image, you know, description of it, a nice little accordion in there, icons for things like, you know, restaurants, bars, you know, sporting activities, et cetera. And there's an inquiry form in there as well. And I've done all of that using custom post types, which is, you know, pretty cool. It took a bit of time to do it.

But that's really, you know, that's ready to go. So if anything comes across, we get a client with a similar kind of project, we can just kind of roll that out and kind of, you know, reuse it. And it's really fun. That's the goal, isn't it?

Just building up your own library of functionality that you can reuse. Yeah. Even with the media queries, some of these themes that get rolled out, I mean, they don't cover every possible media query. I mean, you wouldn't need to, but there's instances where you want to do that.

So you know, you've got the ability to actually go in there and just write fresh media queries for, you know, if you're targeting specific devices, you can do that with ease. And that's really handy being able to override. Yeah. Cool.

Sounds good. Yeah. So if I've been your high-fied designs, your development, it's all done now, right? And you're working at a good pace.

Now, what do you do in terms of like keeping your client in the loop, sharing them progress, or, you know, just showing them prototypes? How do you do that, especially working with WordPress? Because I'm assuming that you've got WordPress running locally for quite a while first before you put it into any sort of server. Yeah.

So how do you handle that? Yeah. So we'll build the site locally using local. It's called local by Flywheel.

I don't know if you've heard about it. I think I might have mentioned it before. Yeah. I've used it.

Yeah. Cool. So I've got a lot of work to do with the web and all those kind of tools that you can use to build a local. Yeah.

So basically, it just creates you a PHP compatible local development environment, which is, and local by Flywheel one is geared, especially towards WordPress. It's actually one click install for WordPress and that's all your port routing and sets up your local host and everything like that. It's really good. Yeah.

Really handy piece of kit. And that's why I needed something that was pretty instant. That does the job. So we'll build the local version of the site.

We'll get it to a level where, you know, it's all kind of, I guess, you know, where the client can actually look at it and say, okay, I'm happy with that, like sign off the build. And they're generally happy with it to be kind of staged, if you like. And then from that sort of stage, I mean, while we're working on that, we're, you know, communicating with the client using really slack or we'll use tools like ClickUp or Trello to kind of let them know about where we're at in the projects. Yeah.

So, you know, what's actually going on within the projects are where are we like, you know, we're right now, we're probably, you know, we're prototyping or, you know, we just finished a design phase. You could be building within local and just kind of showing them progress. And so we've got all of this going on. I think the communication side is really important.

So it's an awkward one because the client always resorts back to email and, you know, we don't really kind of want that to happen. We kind of just want it to flow nicely, you know, and slack and click up or Trello is a great way to do those conversations because you know exactly what you're talking about rather than having to kind of revert through an email trail, especially when you're sharing links to your, you know, your local environment, et cetera. You know, just going through your emails and trying to find the link and the comments that were left for it. There's a bit of a nightmare scenario when they revert to email, but you know, we try to keep everything slick.

So is that how you show the project you've climbed by using? Because I know Flywheel's got like a development server built in where you can run the project locally, but like publish it on top of it. You are up. Is that how you show it to you?

Yeah. So it's an awkward one because the feature that it's got built in, it's not great. What it does is it will work perfectly fine. But if you've got too many resources, so things like JavaScript, things like that, if you're calling a lot of JavaScript files, CSS files, it sees them as resources and then it will kind of stop working once you hit a limit, right?

It's using a third party platform to basically serve that. And you don't pay for it. It's completely free. And that's a downside to it.

So it limits you to the number of resources you can actually serve on a page. Now, if your website is very lightweight, it'll work fine. But there's a lot going on. Chances are it's going to stop working.

So we do have that issue. Now the way you get around that is why you pay for local, their pro package, if you like. And then you've got to kind of use a hosting service provided by Byfly Wheel themselves. And it integrates with local.

And then you can literally just serve it that link directly through that hosting environment that they've got for you, which works with your local installation as well. So that's what they're trying to push you to do. They're trying to get you to kind of pay for it and get the whole thing running properly. Which makes sense.

I'd recommend it, right? But when we've got multiple sites working, that means a purchase what you're doing. Each one. Right?

And then to have an agency package, which is really expensive. And we'd rather not do that. So what we'll do is we'll get it to a level on local. We're happy with it.

Client can actually see it working fine. If we come across any issues where resources are being exhausted, then it's a case of migrating that across to our staging environment, which is visible on the web. So we'll run that off like a subdomain, basically. And we'll just do that.

And then they've got access to it. There's no issues there. Yeah, so that's generally how it works with us. That's the only issue that I found with local when you're using it.

And you run a live link. That's what it's called. Live link. Yeah.

It just can't handle too many resources. Yeah. I tend to use Netlify for my projects. Integrate nicely with GitHub and my Git process.

And Netlify, they give you a unique URL. They ought to generate a unique URL, but then you can customize it. And so it could be something like, you know, myproject.netlify.app would be your custom URL. And you can pretty much just preview the whole site as if it was a live site on there.

There's a lot of people who have launched little site projects and just kept the Netlify URL as the official URL for it. But the beauty of that is, once you have your project or once you've now finally decided on your domain name or whatever it is, it's just a case of updating your DNS. And then you can point that temporary site to your live URL. So it's hardly any work to get your site live then.

And it's good. So Netlify also let you, they obviously build your master branch, which becomes your live version. But then you can also build any feature branches as well to create like staging sites or just to host a particular feature. They can test those features on the live URL before you merge them into your master branch.

They've just that out really well. Yeah, local, have all those features available as well when you pay for it for the Pro Pro version. Yeah, I wonder if local is using Netlify in the background. Netlify seems to be just hosting for everyone at the moment.

Yeah, it'll be interesting to see. I know they work, it works really well with WP Engine, which is another one of these WordPress hosting platforms providers. We use, so we've got our hosting company that we use. They actually launched their own WordPress platform, their WordPress hosting platform called Onyx.

And it's basically WP Engine or Flywheel. It's exactly the same as those kind of platforms, right? But it's their own one. They kind of tailored it for fast, very, very fast loading.

Like they actually stay on there. It's probably the fastest one out there. And that's saying something. So we use that and it's got, you know, get built into it.

So you've got full version control in there. It allows you to create your staging site and your live site. And that's what, that's generally what we use. So we've got the local version.

And then once that's, we're happy with everything there. We'll kind of migrate it across to that environment where we've got the staging version of the site and then the live version running, you know, at the same time and it runs your backups, you know, every hour if you want, daily, wherever you want, it's all running there. And it's a very powerful piece of kit. You know, yeah, it can get pricey, but it does everything you want it to do as well.

Yeah, they're really handy. I mean, anyone getting into WordPress development, I think using one of those tools, whether it's WP Engine, Flywheel, Local, Onyx, you know, highly recommend it. Yeah, excellent. It should probably do a little deep dive into WordPress.

I need to use it a bit more. I haven't used it in a long time, not to any real extent, apart from just creating a blog. I haven't really done any e-commerce with WordPress or anything like that. So once you're done with your site and you've got your live, do you tend to have like a retainer with most of your clients or do you ever sort of wrap things up and hand over and then you've done?

Well, this is a thing, it's usually will kind of set that out before we start the project. So, you know, they'll look at our proposal and that'll be mentioned to proposal as an additional part of it. So like a retainer for maintenance because it's required, right? It's WordPress and updates, security updates are very important.

And we've all seen what happens when you don't keep your WordPress out up to date. You know, things are full apart. So try and push that and most of the time the clients go with it. And even if it's the most minimal level of maintenance, you know, they're happy with that and we'll look after this.

So, yeah, you know, we're there constantly monitoring it, making sure we won't hit update. If the update comes out, we won't hit the update button. So, wait, because it's a case of checking if those six or seven plugins that we're using, including the parent theme, if they're compatible with that update, great. If it takes all the boxes, then we'll go ahead and do it.

But we'll only go and do it on our staging version of the site first. Make sure everything's working fine and it'll push all the changes to the live site. So, yeah, that's part of our kind of maintenance package that we provide. But then, yeah, like with some clients out there that we, the website's always the case of website's built, it's live, have a look at it.

We'll give them a 14-day period if they want to make any kind of changes. They've changed their mind about certain things. And then we'll kind of, you know, if they do have minor changes they want to make, we'll do that within that 14-day period. And then it will be a case of feel later kind of thing.

And if they need anything after that, then they can reach out to us and let's know if they want any kind of additional things like a landing page. If they want to start a marketing campaign, digital marketing campaign, they're going to need unique landing pages for that to be successful. So, that's when we'll get back involved with them. But, you know, we have our clients who just kind of say, well, we need a website, we don't need anything else.

So, yeah. But we try to educate them all to let them know that it's WordPress, it has regular security updates which are required. And we highly recommend you take a minimum, you know, retainer from us and allow us to do those updates for you. Because the last thing we want is a site hacked on our server, especially if it's on our server and our hosting environment.

We don't want any kind of issue like that. So, yeah, you know, we can send top of it, try and send top of it. Yeah, you better off-site on top of it while you can, because if you just let it sit there for two, three years, and then you've come back and make a change. And now you've got a massive upgrade to do first, because nothing's compatible, you know, and you've just removed on.

Yeah. And you're kind of left behind. And then that, that retainable, which may have been minimal, but now turning to a big one-off cost, you know, just to get you back up to speed. Yeah, I've had clients who've actually had to fork out for, you know, three to four days work, because they decided they didn't want to pay a retainer.

But now they pay for three to four days work for me to get everything back to, you know, up to date, if you like, from a WordPress installation, which is about five years old or something, which is never updated, right? So, yeah. Yeah, so it's a big process, isn't it? It's not just, you know, designer site and put your live for a lot to take on.

Yeah, there's a lot to it. And I think you've got to be transparent with the client from the beginning. So, let them know about these things, because they don't want to hear about it afterwards, right? You just got to let them know right from the start.

This is what's involved, and we recommend this, this, and this at the end to make sure everything's still smooth. Because look, we want to keep their business, right? We don't want them going elsewhere, so we try and keep everything as transparent as possible. Nice, okay.

Anything else that we missed? So, we've covered the design, we've covered the frameworks and tool sets of the build process, the client communication and all that sort of stuff. So, we've covered the whole gamut really of sign new projects. I mean, obviously, you're going to recommend WordPress, right?

Game forward. Yeah, yeah. I mean, I recommend really. I suppose it just depends on the scope of the project.

If it's something small, have a look at the site-exite generators. They're really easy to pick up, and they're actually quite fun to work with as well, because it's more than just writing plain HTML, you are adding a lot of logic in there. It's similar to writing something like PHP. But what you end up with at the end is a very lightweight, simple site, but then if you need to reach for something a bit more heavyweight, whether that is WordPress or whether that is a different CMS, then it depends on the job, right?

Yeah, I think one of the key benefits of these site-exite generators is the fact that they're so lightweight. One of the bits that I actually missed out on my process was the testing part of the site, so making sure load speeds are up there with Google's recommendations. And the thing with WordPress is a word of warning is, there's a lot there, and there's a lot of resources that it's basically pulling each time it's loading in a browser. So you've got your jQuery libraries in there, you've probably got your font calls in there, you've got maybe this Ajax, and there's all kinds of stuff.

Now, the more plugins you add, the more it's going to add on top of that, right? And it just slows down your load times. So you're totally very worried about that, but I think these site generators that you're using, they avoid a lot of that. And in comparison, I think they just beat WordPress when it comes to load times, like, what it is.

They do, yeah, generally, the Google Lighthouse score is always in the high 90s. There you go. I think you must be doing something pretty wrong to get below 90. I think my site is on 99 or 100 at the moment.

Yeah, the reason is it's doing all that heavy lifting is part of your pill process. So it's doing all your image optimization, all of your template processing, all of your SaaS, CSS processing, your JavaScript bundling, your minification and all that sort of stuff is happening in your bill process, which can take a bit of time sometimes, as your site grows. If you've got a blog with, say, 500 posts on it, that bill process could take the best part of 10 minutes, maybe, which is quite a long time. Every time you hit save, you might have to wait a few minutes.

It can add up. But what you end up with at the end is a very clean, lightweight website. So it's your way as WordPress is doing all that processing on the fly on the surface. It is every time a person goes to a page, then having to look through the database, find the content and survey up to you, whereas the static sites are doing all that processing offline, and then giving you your final result.

The downside is you don't always get real-time information because you always have to run a build to update your website. So if a visitor was on your website currently and you wanted to push them an update, they wouldn't get that update until that bill process completes, whereas with the WordPress, if they refresh the page, they'll get waivers to latest. So it's a bit more nuanced than that. There are ways of having that bill process be automated.

But there is still going to be a bit more to late. It could end up with a slightly older version of your site, a person viewing a slightly older version of your site. Yeah, we get that with WordPress, we'll use a caching plugin to help speed the process up. So it'll do all the minification for you.

It'll build static pages, leverage, browser caching, all that kind of stuff, like the really important bits and pieces. And once you get that right, with the right plugin, there is one that we use. Maybe we can do another episode talking about some of these plugins, like essential plugins. But there's one that we use and there's some settings on there which we kind of make sure we replicate across every site.

And it tends to always give us a score like in the 90s, if you like 80, 90s, if you like. So just making sure that those settings are done and your caching's there. It helps. But then you've got the problem of client making changes to this site, saving, unable to see the changes, they're reminded to clear the page cache.

Do you get that issue? But then you can kind of set your settings within that plugin to kind of clear the cache on the fly, if you like, after x amount of days or if you like. So yeah. Yeah, okay, cool.

Cool, good stuff. I think that's pretty much covered it. So you started doing a project these days. So start one, pick something on that.

Hopefully this was useful. I've got some ideas because I think this landing page that I'm currently working on, I think it is going to end up in WordPress. You know, the client has thrown the WordPress name out there a few times in conversation. So that's where it'll end up.

It always gets mentioned with me as well. That's what it's like. Yeah, it's fine. It's all good.

All right, good stuff. Catch up with you next time. Yeah, we'll catch up then. Bye.

Thank you for listening to today's show. Be sure to subscribe in your podcast player and feel free to drop us a rating or review in Apple Podcasts. You can follow the show on Twitter at its best FM. And you can find the show notes for today's episode and a full archive of all shows over at inspect.fm.

You know, I'm always getting like dry mouth. I'm going to call it. I'm always coughing this off. I'm trying to be here today.

Yeah. See that fixes it. Which beer? I am having a rude on look.

You can't go wrong with a lazy Jane. Yeah. A lazy Jane's good man. Yeah, what you got?

I'm just going to pint of water. That's it. No, I'm literally just trying to be here just to see if it feels different on my throat because whenever I drink water when I'm recording, my throat is so dry. And I know it is.

It's like the complete opposite of what water should be doing. And I just keep having to clear my throat and I've tried hot drinks. I've tried cold drinks. It's not when you're talking and you're talking a lot.

Your mouth starts to get dry and dry and then you just want to take it because if the water water will be the worst thing to have because it'll go down the wrong way. It's weird. It's weird. It doesn't do that.

It's weird. Yeah. But like I said, I've tried hot drinks as I thought maybe, you know, my throat needs warming up or something. I don't know what it is.

So that's it. I think I might need to get the hardest stuff in the club. Try and you want to try to stout or something smooth. Yeah.

Yeah. I think it's something like that. That'd be good. Get John Smith's.

I had it one ago. It is very smooth. You almost forget your knuckle. Yeah.

You should remember then.