 I'm a wanderer, so sorry in advance to people that want to take notes and not track and to the camera guy, sorry man. So yeah, I'm talking about how to scale your business with WordPress or lessons from work in WordPress that I've gleaned being self-employed then becoming a small business owner or really a micro business owner and then a small business owner over the last 11 years. It's been a fun journey and I'm hoping to share a few stories and tips with you today. I was thinking about ditching that and just kind of wrapping the whole thing around quotes from Terry Pratchett. I can see that some of you know Terry Pratchett by the smiles on your faces. He's a British satirist, humanist, fantasy writer basically. He writes funny novels. But yeah, he taught me a lot about life, very formative reading when I was a teenager and still now. And if there's one thing you need to know about running a business, it's that you need to get paid. So one of the best lessons I learned from Terry Pratchett was about how to do this. Speak softly and employ a huge man with a crowbar. Yes. So yeah, obviously cash flow is one of the secrets to running a small business, unlike businesses that get VC capital or are floated on the stock market or have access to some kind of magic trust fund somewhere. Small businesses are all about bringing cash in and then getting product out. So I thought that was very helpful. So I'm going to talk a little bit about my journey from a blogger where I started blogging in about 2003, 2004, set up a, I guess, a hobby with a business plan in 2006, which was Indie Travel Podcast. And then on to being a freelance developer, which was kind of a nice sideline there. And then finally now to being the owner of a development company, specializing in WordPress. All of that while traveling around the world, started traveling in February 2006 and haven't really stopped yet, which is why I've been professionally homeless for all of that time. And just following the dream, man, following the dream. Or at least a life of new food, new sites, new people, and a want for travel and adventure. So yeah, we left in 2006, from Auckland originally, grew up here. And then in 2006, by the end of it, we had made so many mistakes as we traveled. Things that we hadn't seen in a lonely planet, things that we hadn't seen in a guidebook anywhere, travel magazine, nothing like that. And so we launched a travel podcast way back then, because the travel blogging market was completely saturated. There were like 30, maybe 40 travel blogs. It was just so overdone. Now I think that amount of travel blogs launches about every 10 minutes. And it's really changed. There's a whole professional market. And in fact, I was one of the founding members of the Professional Travel Bloggers Association. And once you get an association, you know stuff's got serious. So that all came to a slowdown, if not an end, when we decided to go to Alcalá de Anárez. My wife Linda decided to go back to university. And if it's hard to make money as a small independent publisher, and especially in travel, it's really, really difficult to run a professional travel blog when you're not actually traveling anywhere and you're stuck in one city for a year. So at that point, I decided to do something that I'd been playing with a little bit. I'd been doing a little bit of freelance consulting for some friends. Their WordPress website got hacked. Their pages were taking 20 seconds to load. Their sites weren't ranking in search engines. And so I decided to kind of flip that and use that work I'd been doing for a couple of friends, a couple of colleagues, and turn that into something bigger. So I started a company called Performance Foundry. And the idea was that we'd take WordPress websites at the point where they had scaled to where the owner or operator that had been using them and building them and adding plugins and adding themes, we could then take that from that point where the business was starting to get hurt because of the technical knowledge of the person that was running the site. And we could then help them scale that up. We could make it fast again. We could make it work again. We could knock out some of the bugs. So that was the idea behind Performance Foundry. And we started it three years ago and every year since then, it's tripled in size. So I'm no guru. I'm no kind of Tony Robbins business god, but I've learned a few things running to keep up with a company that's just growing on me week after week. That's been all bootstrapped as well. It's all referrals to new customers that's powered that growth. Very little advertising, no advertising that worked, and no capital or anything like that. So I want to share some of the lessons from that journey. Before we move on to that, who would say that they kind of work or play on the technical side of WordPress? You get your hands dirty, you get into code, great. Who would say they're on the kind of administrative content management? I get into the dashboard and make things work side of WordPress. Cool, interesting. That's about a 50-50 split for those people sitting at the front that can't see everyone putting their hands up. Nice. Who would say that they are in a place where they're like a business owner or a project owner and it's their job to make things happen? Cool, that's a lot of people here. It's more than half. And how about if you're a student, you're just trying to figure things out and just starting off? Yeah, great. Just a handful of people there. Cool. Thank you for that. Well, let's kick off then with the first idea of how do Kiwi businesses, and OK, the Aussies as well, I think there's enough cultural similarity for this to work. How do we kick off products? Well, I think a lot of New Zealand businesses listen, they make a guess, and they give it a go. So many New Zealand businesses start with just one person. One person that's on the tools, that's doing the work, that's hustling for the jobs, and they're doing everything themselves. There's a lot, lot, lot, lot of tiny New Zealand businesses. Around 70% of businesses in New Zealand don't employ anyone. So that's a lot of owner operators and possibly a lot of tax breaks happening somewhere for someone. So yeah, so that's how we started as well. I was hearing complaints from friends and Facebook groups, places where bloggers were getting together and chatting, and people were complaining about their website speed, website performance. So I heard all of that. I went, you know what? I reckon I can fix that. I reckon, because you look at it, and you're like, yeah, if you're downloading an image that you've taken off your iPhone camera on the homepage of your website, that's about 30 times bigger than it needs to be to display. So OK, that's a problem I can solve. And so that's where it started. And talking with other travel bloggers and trying to figure out what that needed. So that's when I went back to Terry Pratchett again. Just because you can explain to someone, sorry, just because you can explain something to someone doesn't mean it's not a miracle for them. So no matter where you are in your technical journey, if you can make something work for someone, you're like a god, a god amongst men. If you've got a friend who's struggling to get WordPress to update, and you've got, I've heard something about file permissions. Maybe that's what it is. And you can even recommend they talk to their hosting company about looking into the file permissions. And then it starts to update again. Instant win. So you can start really small. And this kind of ties into the idea that D was talking about with a minimal viable product. And so I'm maybe not going to recover that again. But there's three words here that are all really important. One's minimal. It has to be enough to do the job. It can't be a product that doesn't work. I think that's where a lot of people go wrong when they hear about this idea. And they go, oh, we tried doing a minimal viable product. And it was a waste of time. It sucked. So next time we're just going to aim for the end product straight away. Even though it's minimal, it actually has to do the job. It has to achieve the goals that you want it to. It has to be viable. It has to be something that someone wants. It has to have a purpose in its life. It has to be able to go somewhere organically by itself. And it has to be a product. If you're in business, you need people to give you money. Otherwise, you won't be in business for very long. You might be keeping the local noodle shop in business. But sooner or later, that cash runs out. So it should be something that's small enough to measure. It can't be something so big that at the end of the period, whatever it is, you can't kind of connect with it. So you need to be able to measure it. And in order to make that measurement worthwhile, you need to have some kind of defined point of failure and success. Success is lovely. But you have to have a defined point of failure as well. You need to be able to kill this thing off. Most importantly, one of the ideas around Lean, around MVP ideas, is that you're working in a super uncertain environment. As a startup, you're creating something that nobody's ever done before. So that creates a lot of uncertainty. If you're working in an area like augmented reality, nobody knows what this is going to look like. Nobody knows where AR is going to go. Nobody knows how we're going to be using it. So how do you put your resources into something that crazy? Highly uncertain. So you need to be able to have defined learnings from each of these MVPs that you create. Stuff that works, stuff that didn't, stuff that created an emotional engagement and things that everyone just thought was a myth. So yeah, so I talked about viable. And what we're doing is looking for growth in highly uncertain environments. And I think that's something where a lot of Kiwi business literature talks about how we have this small business mentality, how we start small and we stay small. The founder stays on the tools. The founder creates a job for themselves. The founder is not really looking to own a company. They're looking to do the work that they would do for other people, but just do it for themselves. And so in order to scale a business, that mindset needs to be changed. And there needs to be an idea of looking for growth that's bigger than where you're at. So in order to do that, unfortunately, we need to spend. We need to spend time, money, or this is where it gets cool. Sometimes you can leverage the initial time and money you spend to end up not having to put anything else into it. So time, money, or neither. Think about doing backups. Everyone, if you forget everything else I say today, backup your website at least every day. Forget everything else. Just do a backup. That's important. So everyone needs to backup data. And you need to back it up on a third party service. You should be doing this all of the time. And do you remember back in the day? Do you remember, I remember when I was at school and university and some of the first generation have laptops and classes and things like that. And I remember losing work to the blue screen of death. I remember that so well. You get to school. You open up the computer. It makes a funny noise. And you spend the next two classes. Instead of doing your work trying to figure out how to get the stupid things started again. So that's where I learned about the value of backups. But then backups were really hard. You had to get disks and plug them in. And then we upgraded to DVD ROMs. He had spent like a couple of hours once a month just burning DVDs, right? Put them in, take them out, put them in, take them out. Oh my god. But over time, there was value in that. That was essential running those backups. I remember when we were at university and I knew my wife Linda then. That's when we started dating. I remember she was doing this university paper on the effects of the AIDS epidemic. And so, you know, AIDS, shift, A, I, D, S. Perfect. What happens if you miss hit, then hit Control? Select all, make it italic, delete it, save it. I think billions of dollars of AIDS research money probably just get sucked into a black hole of that problem. It's unbelievable. So all of a sudden, this whole backup thing is taking a lot of time and a lot of effort. Because at the end of every paragraph, you're like, right, I'm getting this sucker onto a disk. I'm taking the physical disk and I'm moving it out of the computer. And then I'll write for another 10 minutes. By the time Linda had rewritten that paper about 30 times, she got an A plus. So it wasn't all lost. But yeah, but now backups can be fully automated. If you have to do something in your backup system right now, that backup system's probably failing. And the most difficult thing you should be doing is remembering to plug in a hard drive every now and again. And even though New Zealand's internet isn't the fastest, even finally setting up a backup system into the clouds finally becoming viable here. So you need to invest in money by that drive, invest in time, remember to plug it in. But there comes a point where none of that's necessary anymore because the system is automated. The system's caught up. And so that's one of the things that we need to be thinking about doing. Once you've established that product, once you've established that value through your iteration, through your NVPs, then begin to automate those systems. So that automation might actually be hiring someone or that automation might be a coded, systemized platform automation. So what needs to happen? That's question number one. What triggers the start and the end of this process? And it's been really cool in our tiny little micro business defining a start and an end and a start and an end and figuring out checklists and then moving some of that stuff into code and into scripts and then going, hey, well, if we know that's the start point, what else can we then begin to feed into the start point? And then you start chaining these little micro systems together. And then things really begin to flow and all of a sudden, time's beginning to free up and stress is beginning to disappear. You'll have entirely new stresses. Don't worry about that. But it begins to happen. And inside of those chains of micro processes, there are decisions that might need human intervention or feedback from a system that you need to be able to integrate. So then your systems begin to get smarter and smarter. So how many of those decisions can you map? How many of those can you go, oh, well, every time we ask the client this, they always say that. So cool. Maybe we can map out that conversation that we're going to have with that client. And then maybe we can create some scripts to help them end up with a better product because we know that some people are going to want to do dumb things. And some people are going to want to do dumber things. And we can help them with that because that's what we do. And so as you begin to map out all of these flows, my god, it's boring at the beginning. But the power of that, the power of going into a meeting knowing that, hey, 80% of what's going to happen in this meeting, we know about that. And we're going to be able to do it. So then once again, you can grow. You know that conversation. You know how that's going. You can hire someone to have that conversation for you. And you can do it with a lot of faith in them. So we're talking here once again about scaling is figuring it out, being that owner operator, being on the tools, and then realizing that you're not a genius. You're not some kind of crazy god and the only person who can do this. But it's about downloading it out of your head and into a system. So what next? Next, everything breaks. Every time you add a staff member, every time you add another big client, every time you scale by any kind of multitude, all the systems that work so well for you don't work when there's two people. And you get your communication sorted with that second person and then you need to hire someone else. And by the time you get to four or five people, that phone call you are having every day to figure out who's doing what isn't working anymore. So every time you scale, whether that's one to two people or 20 to 30 people, everything breaks all of the time. And so that's good fun, eh? Really good fun. Hey, so instead of a business story, let's look at a WordPress story. So in order to tell this, we need to think about how do we serve WordPress from a technical point of view? So there's a couple of bits that go into it. The end result is a web page that people can see, right? So before that data goes to the browser, before anyone can start downloading anything, we need to gather together information at a server infrastructure level. We're gonna grab some PHP. So PHP's the language, the code, that creates the shape of the page. And then we need to go and gather data. And data comes from a database called MySQL normally. And so you can go and grab that data and pull it in and that'll put the words, the pictures, and all of that kind of information onto the page. And then there's external resources that we need as well. So maybe we need to go and get a certain font from somewhere else on the web or something like that. Font's a bad example because it happens afterwards. But maybe we need to pull some data from a third party API, for example. And at that point, we can then begin to send the page to the browser. Everyone's going, oh my God. This is that little flash of white that happens in your browser before anything appears. All right, so when you hit enter or click and the page goes white and you wait, this is what's happening. We're gathering and processing all of that information. So all of that's called your response time. That's how long you wait on the server to give you a response. So I'll show you an example I was working on at the beginning of this week. So we had a new client come to us and they came onto our managed hosting platform. And what we saw in the graphs terrified us. So you can see here we've got the PHP is in blue. So it's down the bottom. Oh, someone gave me a laser. Oh, oh, oh. So you can see the PHP's down here in blue. And then this is my SQL. So this is getting information from the database. And then the little spots of green up the top are occasionally going out to third party APIs to get some information. And what we see is on average, this is across about a 20 minute time period. It's pretty flat. There's no big spikes or crazy stuff happening. This is regular traffic creating regular results for this page. And in microseconds on the left, you can see that we're taking between 2000 and 2500 milliseconds, milliseconds, milliseconds, sorry, to gather that data. That's two and a half seconds of white. Click on the link, go there, and you just sit there for two and a half seconds. You can imagine how much patience you've got for that kind of stuff. And so does everyone else. So that represents a lot of lost traffic, a lot of lost value. So what we decided to do was to look at the biggest problem first. I like D, where can we add value? So how can I solve this problem in five minutes or less? Because these guys are just paying us a hosting price. We're not getting any kind of money to actually fix their website for them. We're not doing development. They've just come on our hosting and we're not happy with that at all because that's a really bad ad for what we do. Come to performance foundry, your website will take two to five seconds to load. Hey, you can sell that. Yeah. So we decided to focus on this major problem, this big tan kind of bit here. And what we did is we replaced something slow with something fast. So we replaced standard MySQL with what's called a Redis cache. So it's an object cache. And what it does is instead of going to ask the MySQL database for every piece of information, every time it asks for information, it stores a copy of it kind of in the RAM in a faster way to respond. So every time that question goes back again, we don't need to ask it of the database. We can just read it here. So only new information that we need to ask goes to the database because databases are slow. Even if you, say, replace MySQL with something like MariaDB or Aurora and people that aren't techie, you don't care, you don't have to know. But even if you replace it with something like that, even if you replace it with a read-only node, it's still gonna be slower than being able to grab something out of Redis. So all we had to do here was because we had done the work in the past and because we work with our great partner on our hosting side, we have a file that we copy into place and magic happens. It's brilliant. So wherever you're hitting pain in your business, look for those big tan bits. Look for where all of the time, all of the energy, all of the stress is being sucked up into. And then try and swap something slow for something fast, something complex for something easy, or something easy but slow for something complex. You front load that work, right? Redis isn't overly simple. Otherwise everyone would run it all the time. But we've done that work and so earlier this week, it took me five minutes to fix. So these wins can be big like that. I mean, we just dropped two seconds off the load time of the site. Not bad, not bad, especially if you don't get an invoice. Or they can be incremental and slow and build up. But whatever's happening, they should be moving you forward. You should have a defined idea of success or at least a direction to be moving in. I believe we have time for one more example. And this is another important one. Avoiding one-to-one connections between resources and whatever the output is. So this comes from an e-commerce site that we've been working on for a while. Same kind of graph, right? So you've got the PHP in blue, the MySQL in tan and then the external in green and all of that adds up to create a wait time or response time. And we can see wherever there's high throughput, see that spiking? That's more people coming to the site over the week. So that's three days. They have their peak times of traffic. And we can see, here's the end of one day into the second, into the third, into the fourth. And as that spikes up, so does this. So there's a one-to-one relationship between the throughput and the output and this kills businesses. If every time you bring on a new client, you have to do the same amount of work and that amount of work never gets smaller, there's only so many clients you can bring on before you have to hire someone else. Exactly the same thing happens with a server. If you have to do the same amount of work every time you render a page, the more people, the more resources, the more you're spending on server space, or server power. So we wanted to break this relationship. That was our goal. And we found the issue, I'm gonna skip through this a bit, technical people probably get it, other people really don't care. So what we did was we found that the page template was by far the outlier in time spent. And we found out that within that, in the brown here is a call to something called wpPostSelect. So every time we're generating a page, we're asking the database to select some posts for us. Cool, there's our problem, bad database query. It looked further. We found that the My Account Orders page was taking up to 60 seconds to load. Oh. Put your hand up if in the last five years you've waited 60 seconds for a page to load. Oh yeah, a couple of people, I bet that's your own websites too. So this was painful. This was painful. And we found out that what this was doing, it was doing it 20 times per page for one example that we found, it was taking up 99% of the time, which in this example I pulled out was 25 seconds. 25 seconds for 20 database results. Oh my God. Yeah, so good fun. But the great thing is we had identified what the problem is. The problem was this one-to-one connection. Every time someone opens the orders page and they look at their past orders, no matter what we tried, the database was looking at every single order, every single person had ever made in the history of the website, and then returning 20 results. Not efficient. It's okay after your first thousand customers. Once you're into six figures worth of customers, that's no longer okay. So what we did was three steps. So here's everything going absolutely crazy. And what we did, and this is great, we just removed that link from the menus. Stop that puffy crashing the server. If nobody can find the link, very few people are gonna open it. Unfortunately, also a link to that, we had an every single email that people got after making a purchase, so we couldn't quite kill it off. But yeah, just remove the problem. So that was our first step. And you can see here that we go from this crazy, crazy stuff down to something that looks a bit sane. And that gave us a space that we needed to go and rewrite the query. So what we ended up doing is, once again, working with our hosting partners because they're going, your database is locking up. We're like, yeah, we know. So working with them, we came up with a new MySQL query. In the end, they tested the query against the staging site. They went, hey, this is gonna be more efficient. They gave that to us. And we spent a couple of hours figuring out how to replace a core word WooCommerce function and change out the database query. And we tested all that, that looked good. And so we got to deploy it. And yeah, this was the deployment point. And you can see here, it just trickles away to almost nothing. So whatever happens, avoid these one-to-one relationships in your code and also in your business. So back to Sir Terry, knowing things is magical if other people don't know them. It doesn't take a genius to be able to look at those beautiful graphs and go, oh, there's the problem. But if you are able to read that data and actually take an action on it, then you're approaching magic. So your project can grow. Test, play, learn, be a Kiwi, have a go. Systemize, optimize, design for excellence. Replace slow with fast. 80-20, that issue. Find those big, big pain points and work on those first. It's a whole Pareto principle idea that 80% of the effects come from 20% of the inputs or you can flip it around if you want. Really important for figuring out bottlenecks and problems in code and in business. I remember that everything breaks at scale. So don't worry about that. It's all gonna break at some point. Yeah? Cool, because I'm an ex-teacher, let me give you some homework. If you enjoyed the stuff around MVP, around iteration, around growth and uncertain environments, then a great book for you is the Lean Startup. If you enjoyed the idea about automation and building a company instead of building a new job for yourself, then a classic, but, you know, little bit cheesy, but still good fun, EMA3 visited. If you like the ideas around continuous improvement, 80, 20, doing big things, then for inspirational reading, I'd go with the one thing. For serious, nitty-gritty, painfully boring technical stuff, I'd go for design for operational excellence. I started with a Pratchett quote, so let me wrap up before we go to questions with one. Sorry, Valdrick. Why bother with a cunning plan when a simple one will do? I've been Craig Martin, thanks very much. Do we have a mic runner for questions? Yeah, cool. Thanks, man. Maybe I'll switch onto this mic for questions. So if you've got one, wave your hand in the air. I've got one question for you. When you do analyze which components of my SQL PHP, what did we use? Is it any resource that's available or we need to buy it? Sure, yeah, so it's available, but you need to buy it. So those graphs came from a tool called New Relic, which is, you can get a free trial and play with it, but it's only available for servers. So if you're running your own site in a shared environment, so if you're paying maybe a few dollars a month just to have someone else manage your hosting environment for you, you're really unlikely to be able to use it. If you're running your own VPS or anything else, anything containerized, or if you're in charge of your own infrastructure, you can get that. They have different price points. 75 US a month is more than enough to get all of that WordPress level data. And what's really cool with WordPress is you install a module of New Relic and you can actually break things down by plugin, by hook, by theme. So you can go, what's wrong with this website? WordPress plugins. Ah, Divi, uh-huh. By the way, that was Divi, that first example that I showed that using all of those database resources and making it super slow. So Divi can be optimized, but yeah, that was that example. It's a popular theme that a lot of people use. So you really wanna up your case game if you're using any of those themes with a lot of options. I guess bouncing off that, if you've got an option, update your PHP from PHP 5.0 anything to PHP 7.0 anything and your website will go about three to eight times faster. So that's something else we've learned from New Relic, just making that change and seeing that blue line just drop off a cliff. Really cool to watch. Hey. I've done patient sites to speed it up. Uh-huh. Have you got experience with Cloudflare because I'm just getting into that. Yeah. And wondering how successful it is and how I've used it, it's easy to use. Uh-huh. But is it a good option for stopping that slowdown? Great question, great question. Terry, is anyone speaking about that kind of infrastructure stuff in our schedule? Because I just wonder if someone's going into it in detail, I won't do too much. I don't think it's in great detail. Okay. I think I'm wrong. So let me do a quick, yeah, this time. Let me do a quick rundown on that. So Cloudflare is a service that's free to get started on and it's pretty good. And what it does is it takes a copy of every page that's requested and all of the resources on your website and it puts them at dozens of different points around the world. So instead of a user in Auckland having to go all the way to the server, say in Rochester, New York's a popular place, all the way up there and all the way back to New Zealand again, there's copies of the photos of the JavaScript of the CSS, all just sitting and I think they're out of Sydney. And so you're just jumping over to Sydney and back again. So Cloudflare is really good at taking those static resources and putting it closer to your audience and they have these points of presence pops all over the world. There are other companies which are paid, which are faster and a bit more efficient, but for free, I don't think you can beat it. Cloudflare also has a whole bunch of other tools that help with optimization. You just flick switches and see if your site's faster or slower. So yeah, it helps a lot in terms of speed because everyone's server is in one physical place in the world and so by using Cloudflare, you're putting your resources closer to the people that are accessing the site. What Cloudflare doesn't do is any work on those core resources themselves. So Cloudflare can't make PHP faster, can't make the database faster. What it can do is reduce the load. So web pages are asking fewer questions of those resources. So what I demonstrated here, Cloudflare doesn't really have an impact on with the exception that each person loading a website and maybe downloading 50 images, those 50 images Cloudflare is paying for instead of your host paying for. And by paying for, I mean technically, they're doing the work to deliver and send that information. So yeah, does that make sense? Yeah, yeah. If something like Divi is slowing it down. Mm-hmm. That it's not calling on Divi directly, it's actually, it's just a flat page. Yeah. And it's not actually hitting ever putting the database. Yeah, it's possible. Yeah, sure. Yeah, yeah, yeah, yeah, it can do a full, kind of what's called a reverse proxy. So the first person that loads the page, Cloudflare goes, yep, this is what the page looks like. I'm gonna push that information to all of these points of presence and then I don't need to speak to the database again. So yeah, I wasn't sure if that was on their free plan or their paid plan. But yeah, so if you can get that full page cache and then push it out to your points of presence, then yeah, you're only talking to the database once. And that can work really well with brochure sites with semi-popular blogs where people are leaving comments and doing things like that. Every user interaction's gonna break that. And if there's lots of Ajax on the page where it's needing new information from the server, that's gonna break it all the time as well. And so that'll break that full page cache. And yeah, and Divi is pretty heavy. Most modern themes are pretty heavy with Ajax interactions. Some of them don't need information again from the server and some of them do. Yeah. Time for one more quick question. Okay, yeah, a less technical one. So somebody comes to you with a victimly slow side. To what point do you speed it up? I mean, obviously any improvement for them is an improvement. Yeah. But how far do you go? Right, so in terms of what our business does is we, well, one of our products is offering hosting. And you know, with that, one of the things we sell on is the fact that your site will be more secure. It'll be faster. Faster sites equal better SEO equal, da, da, da, da. And so that's not an uncommon value proposition from hosts. Right? And so what we do after they come on, because we can see all of this cool graphing stuff, if we can identify a couple of big pain points, excuse me, then we just jump in and fix it. If it's gonna take significant amounts of effort, then we put together a proposal and do that. So yeah, so for us, and I think the moral of that is, if you have IP as a business, if you have a way of being able to help people, if you can front load a lot of value into those initial interactions, then you're gonna get repeat business and you're gonna get referrals. And so that's what we're aiming to do is not over deliver at the beginning, but make sure that, you know, if the problem wasn't with their hosting and the reason they moved towards was to speed up, if the problem wasn't actually their hosting environment but their code, we can see that too and we employ people that can fix that. So hey, if it's gonna take us a couple of minutes, let's just jump in and do it. So yeah, so just front loading that value and making that work. So yeah, cool, thank you.