Hello, and welcome to a new season of the Website 101 Podcast, the podcast for people who want to learn more about building and managing websites.

With me as always, as we begin Season 7, is Mike Mella.

And Amanda Lutz.

That was a great pause.

Hi, Sean.

Hi, Mike.

How are you?

Happy Season 7.

Happy Season 7.

It's hard to believe that this podcast has gone on for seven seasons, so I'm really excited about that.

I'm also very excited about our topic for today, and that is when and how to say no.

This is a crazy topic.

I still have problems with it.

Like in my professional life, in my personal life, I've gotten really good at it.

Yeah, Amanda's always saying no to me when I ask for help.

False.

An absolute falsehood, Sean.

Why would you lie like that?

No, that's not true.

No, it's not true.

Amanda's very helpful.

But yeah, it can be very hard to say no or know when you should say no, especially if you're new to running a freelance business, and that's kind of what we're going to go into today.

Yeah, and it's not just for web developers, though.

It's also for clients, right?

When clients need to be able to say no to a prospective developer or designer, whatever that they're working with, and also when those people need to say no to a client, right?

It's all that.

Yeah.

Yeah.

So what do you guys think about...

What's a good example of when you would want to say no to a new project?

So it could be a new client and new project, or an existing client and a new project with the existing client.

Well, I think what happens a lot of times with brand new clients is they'll just nickel and dime you.

I've had many, many intro meetings where we talk about the project and if my skill set will handle it.

And then we get around talking to my rate or to the cost of the project.

And you can see it in their eyes where they're either surprised or they were expecting that, but they're just not going to pay it.

And it's like, I've learned over the years after many mistakes is that if there's any, a little bit of hesitation is fine, but if they say anything at all to try to work your rate down, just know that it's, you don't have to stand up and throw water in their face and say no immediately, but definitely know that this is going to be just a bad scene.

Do not take this project.

Yeah, I think one way to alleviate that is to talk about budget as early as possible in the process, because if your client or potential client doesn't have a budget or an appropriate level of budget that is going to satisfy your needs to live the amount of time required for the project, it's just like, oh, sorry, I don't think we were going to be a good match, or maybe you could ask them, hey, can you add an extra 50% on that budget?

Because realistically, I think that this is going to be a more expensive project.

And if you do that early, you're not wasting hours or days of your time putting together proposals and stuff.

Yeah, this overlaps with some of the other episodes we've done about budgets, I believe.

We've done one about red flags.

Red flags, so like when to recognize red flags with a project and whatever.

So it kind of has to do with that.

Budget is always the main thing people seem to fixate on.

So yeah, you want to make sure upfront that you're all on the same page, otherwise you might have to say no, put it that way.

So I have another reason that you might want to turn down a project.

And that is something that's, I think it's somewhat common, and that is that the client doesn't have a clear idea of what they want on their project.

Now this can be, this can go different ways.

It depends on what your role is.

If you're someone who just wants to be told, this is what we need to do, can you please do it and what would you charge, then that's fine.

But some of my projects, I actually do a lot of the project planning with them, and because they're just not used to some of those big projects.

So if that's the case, then that could be okay.

But if you're someone who's just a developer and I want to write code and whatever, and they don't quite know where they're headed with their project, that could be an issue and you might need to say no.

Unless you can, you found the magical unicorn that they're just going to keep paying you.

If you can get an hourly rate from them and they don't know what's going on, help them out as much as you can, but you get paid, you know?

Oh, you want another meeting?

Cha-ching.

Yeah, I know, right?

On the flip side of this, though, I had a client a few years ago, I did some work with them and they were like, they were okay to work with, but they were a little bit flighty.

And then after the few projects that we did together where everything was fine, I didn't hear from them for a very long time, and I found out they had health issues or whatever.

But then when they started contacting me again, it seemed like they would call me every six to eight weeks and be like, got a new project, it's with this client, let's work together, when can you start?

And I'd be like, and the first couple of times it was like, I'm busy, but it's like, oh, I can start next week.

And they were like, great, I'll call you next week.

And I never heard from them.

And then like six to eight weeks later, they would call me again.

And about some other project completely, got a new project, it's for this different client.

We got to start immediately.

And what's your time availability like?

And after like two of these calls, it's just, I just always said yes to them because it was funny to me at that point.

Yes, I can do this project.

I can start tomorrow.

Radio silence.

Two months later, the phone call from them again, new project, new client, when can you get started?

And it's like, tomorrow!

Radio silence.

Never heard about it again.

So there are some times where it's like, you know, you just say, always say yes, because, you know, so often it doesn't work out.

Amanda, maybe you should have started charging them for those phone calls.

Every time they have a call, when they talk about a project, a hundred bucks.

I did record that in my timekeeping so that if an actual project ever came through, some of that would be eeked in a little bit, but like it never happened.

Yeah, good call.

I've had at least two clients where they're like, oh, let's rebuild the site and be all right.

I prepare a quote, whatever, and never hear back from them.

And I followed up like three or four times.

I set up a schedule where I send an email and not now, later.

And I give up and six months go by and I listen like, let's do it.

And it's like, all right, remind me what we're talking about because I totally forgot.

Who are you?

By the way, my rate has increased since then.

So right.

It's been six months.

That's the delayed fulfillment rate.

Well, that's why a good point of advice for anybody is anytime you put together a proposal at the bottom, the rate is good for 30 days, 90 days, like you got to put a time limit on it so it expires, and if they come back to you later, you can now you can bump it 10, 20, 50%, whatever you want.

That's a good tip.

Yeah.

So something that often happens with me is the projects that come to me, one of the first things I always ask is who's my point of contact in this project?

Like who am I dealing with?

And hopefully it's one person or a small team of people.

But one of the other sort of reasons one might turn down a project from my perspective is you're dealing with way too many people.

There's just like a group of like a dozen people.

Yeah, exactly.

Board of directors, you have to, or the CEO is going to be involved once in a while, all kinds of stuff like that.

It's like, no, that project is not going to go smoothly.

So I might say no to a project like that.

How about you guys?

I fortunately never been in that situation.

I've only heard of its no direct experience.

I have had a few projects lately where it's like the emails, especially the initial emails, will have like eight people cc'd.

And it's like, I don't do any of these people matter.

Do I need to like be in touch with any of these people?

But like Mike said, so long as I've got like that single point of contact, whether it be like the project manager or, you know, just like a sort of more design, just somebody like owning the project, yeah, it definitely helps with that.

Yeah, if they have too many cooks, as long as they keep it internal and they only talk to you through one person, that seems like an acceptable way to work.

Yeah.

Yes, although I do think that it's also helpful to say at the front of the project, whoever needs to be involved should be involved for the whole thing.

Don't bring someone in a month from now who suddenly needs to weigh in on all this stuff and they don't have the previous discussion knowledge that we all have.

Get them all in at the beginning.

That's another, that's not how to say no, but a bit of a tangent there.

But anyway, sometimes that's important.

Yeah, but I feel like as just the developer, as just the code monkey, the worker bee, I mean, I'm not in a position to say that to a client, especially if I'm working with the design agency and then it's actually their client.

And it's like, I'm definitely not going to say to the end client, I don't care what your employee turnover is.

That's just not our position to say.

Yeah, well, these experiences I'm referring to are more like, because I often do the design stuff for my projects.

In a design context, if you're, I'm going through this right now actually, where it's like, we've done like all this work on design, and then suddenly a new person's brought into the project.

And that person has all these opinions that my response is, well, we already nixed that.

We talked about that two weeks ago.

You weren't here.

We've discussed this idea.

We said no, but now I have to teach you about all this stuff, you know, that it's more like that.

So it's more of a designy thing, I guess.

Yeah.

But the new guy wants to make his mark on the project.

Yes, that's right.

Always.

Can't say I blame him.

Okay, so I would think that the biggest time to say no is obviously just when you don't have time in your calendar, you're already...

And I have the biggest problem with this.

Anytime a new project is brought to me, I'm like, screw you, McDuck, with like the dollar signs for the eyes.

And I just, I always, I always want to be taking the projects, but with the podcast, with the teaching, with the client work, with the family life, with the trying to get enough sleep every night, with trying to be better to myself, it's, it's really hard to balance that.

Yeah.

Oh, I definitely feel you.

So during COVID, we had that three year period, that was the busiest I've ever been for freelancing.

And I got so busy because I said yes to everything.

I was like, yes, yes, yes, I can do it all.

Yes, I'll do everything.

And I ended up working longer hours on the weekend, and I was completely burnt out.

And the end result was that a long term agency client, I did not deliver what I promised to them.

They went and hired another developer to finish that project and slowly transitioned away from me because I f***ed up.

Sorry.

That's all right.

Drop a beep on my F-bomb there.

Sorry.

Maybe we should start swearing anyway, who cares?

In that case.

So, yeah, if you don't have time, it's probably a good opportunity to say no, step away.

Or maybe you can make a little bit of time for project management and hire on a subcontractor, which is probably what I should have done for a couple of those projects that I had at that time.

I would still have all of my clients, especially that big one, right?

And a lot more money.

Yeah, we should do an episode about working with a subcontractor, subcontracting people.

Have we done anything like that?

I don't think so.

No, we haven't made an episode about it, but I have subcontracted occasionally, but mostly for skills that I don't have.

In other words, hiring Amanda.

Hiring Amanda or other people, not for time management, because I didn't have the time to do it, which I just said I should have done.

Yeah, it's tough, though.

I'm reluctant to engage in a subcontractor relationship that's really substantial because I'm nervous about handing over control and their quality of work.

That's the thing I'm concerned about is I have standards for myself.

If I'm hiring somebody that I can afford, are they as good as me?

I don't know.

Probably.

We overcharge.

Yeah, we can get some junior to do the grunt work.

Yeah, I think this would make a good episode because I do want to talk about onboarding of a contractor, maybe trying to set up a long-term relationship, but let's move on.

I think this may be good to get a guest.

So hello listener at home.

If you know of anyone who is a contract developer themselves, but they subcontract at work, Sean's got good experience, yes, but it would be good to be able to talk to somebody else just to get more feedback, I think.

Oh, absolutely.

I would love to talk to somebody about that.

Or if you are that person.

Or if you are that person, yeah.

Yeah, let us know.

So another thing about when to say no to a client is maybe if you've got ethical concerns about the project.

It could be some LGBTQ thing or political thing, or maybe you got approached by a client that does porn and you don't want to do porn and have whatever reason.

I would do a porn site.

Why not?

Content.

I wouldn't be content on a porn site.

Right, right.

You'd be coding it.

Build the site.

It's code, yeah.

But there are lines I also would not cross.

Yeah, yeah.

Yeah, I've had that discussion with people before about adult content and should people stay away from it.

I mean, I don't know.

I suppose it's a matter of whatever you're in.

Well, this is exactly what we're discussing here.

So yeah, LGBTQ.

So like maybe you hold a particular position, political position or whatever, and those people are not in line with that.

That could be a reason.

I had a situation like this a few years ago.

I had a client, an American client, and they paid me a ton of money because it was like you said, Amanda, earlier where they just kept coming back and changing things, but they just throw money at me to do it again.

And I'd be like, all right, let's do it again.

We just were undoing what we did three weeks ago, whatever.

And they were nice people and everything, but they were a, without getting into too much detail, they were basically like an alternative medicine wellness kind of thing.

I won't get any more specific than that because if I do, people would know exactly what it is because it's a very specific branded name.

Anyway, at the time, I was kind of, I was kind of, I was kind of newer to the stuff and I took all this work on from them, but I asked myself recently, like, if they came to me today and asked me to do that, I would not do it because I'm more of a pro-science kind of guy these days and I just don't support alternative medicine, you know, endeavors.

So I wouldn't want to, I mean, there were nice people in that, but it's just not for me, that kind of project.

So that would be an example where I have an ethical position, I guess, where I just, I wouldn't support that.

So I wouldn't take on work like that.

So be aware of those kinds of things in yourself, in case someone approaches you and you're wondering, you know, should I do this or not?

It's important.

I too worked with a wellness industry person.

She was great.

She was a really nice person.

But part way through my term working with her, I was like, man, I don't know, I just, I didn't like her content.

She was a nice person.

I just didn't like being responsible for the stuff that I don't agree with because like Mike, I'm also very pro-science.

Yeah, there could be like an anti-vax thing or like trucker convoy thing, and you have the opposite opinions, whatever.

It could be a million different things that you don't agree with and just evaluate that.

You could be on the right and you're asked to help somebody with the leftist website or you're on the left and somebody helps you, wants help with their rightist website.

So here's a question, though.

Would you work with a client who, I mean, not like morally you were against, but like if they sent an email that was just chock full of spelling mistakes or if they used like LeetSpeak and like letters instead of actual words or just something like something else like that, that would maybe just like in a personal setting would like get your backup, but like would you be willing to work with someone like that?

For like spelling mistakes and grammar mistakes, in my past life, I was in English as a second language teacher.

So I would just assume that it's coming from somebody who doesn't speak English as a first language and I worked with them.

So a quick side story here, I was going to hire a contractor once, not a web, this is not a web thing, but someone to do work on the house.

And he gave us this like a document, a big report thing that was involved in the work he was going to do.

It was a pretty big job.

And we live in a bungalow and he misspelled the word bungalow everywhere in the document.

Were they misspelled the same way?

Or was it just...

Yeah, they were.

I was talking a different way.

But it's just like there's spell checker exists.

I ended up not hiring the guy partly for that reason with other reasons, but also that because I just thought you don't have the attention to detail that I want from a contractor to do this job, because you didn't even bother to do a spell check on a professional document that you handed a client.

So that's something to consider, I think, yeah, maybe.

Fair enough.

I'm just going based on my experience.

I'm a little bit more forgiving about that, I think, just because it could be ESL as a second language.

But if it turns out it's not, and it's just somebody who is kind of lazy, as Mike suggested, that might be something like that, maybe not.

Variable equals Amanda.

If Enjoy Website 101 Podcast equals True, then go give us a positive review on Apple Podcast.

I can't even do it with a straight face, or wherever you get your podcast.

So what if you heard bad things about the client that you're being, you know, approached by?

You've got other developers, like friends like we are, and it's like, oh, I've worked with them before, that's a bad, don't do that, it's a bad scene.

That could be a reason to say no, right?

Depends how much I trust the person who told me the story.

Well does it?

Like if you didn't know them, if you knew them through the community, and you just heard that, like I feel like I'd still, if someone worked directly with that client, I think I still would say, oh, that's a red flag, you know?

Because how hard is it, it's pretty hard for someone to get in someone's bad books enough that they will tell another person, don't work with these guys, you know what I mean?

I've told Sean, I remember Sean, there was a project, and I was like complaining about this particular client, and then you were like, actually they contacted me, there's not that many craft developers in Toronto, and we laughed about it, and then like a year later, after I was still working with this client, and I was complaining about them again, and you laughed, and you're like, I dodged the biggest red flag right there, and I was like, yes.

Oh, yeah, yeah, yeah.

But you're a trusted person that I know is not going to be exaggerated.

Yes.

And then recently, I acquired a couple projects from a mutual friend of ours.

And one of the comments that this mutual friend said was a bit of a pain in the ass.

And now that I've experienced it, the next time this mutual friend, this mutual colleague, would give me a heads up about a potential client, I would take it a little more seriously.

You sent me a client once.

You didn't, I think it was like you didn't have time for them or something.

And you I didn't have time, but also they wanted somebody more project managing and designing and I'm like, code, that's what I do.

So yeah, I took that on and they're nice people and everything, but they it was so difficult to work with them.

And I did end up firing them.

But then they ended up kind of begging me to not fire them.

Like giving me more money itself.

So eventually I took it back on and finished the thing, but yeah.

So Mike, why were they difficult to work with?

It was mostly because they didn't respect the sign off process.

So for me, especially in the design phase for me, like if you're doing design work and then you say, okay, how do we feel about this?

Looks great.

And I eventually got to a point where I specifically said in emails, do you sign off on this?

Like we'll proceed with this element or this design, whatever.

And they would say, yes, go ahead.

And then two weeks later, they'd say, you know what, change their mind.

I don't want to do that.

And I'd be like, it's going to cost you way more.

They would pay me more.

But eventually I just got sick of even that.

And I was like, forget it, I'm done with this project.

Yeah, that's really frustrating.

And I would definitely chalk that up to poor communication and decision making on their part.

Yeah, it was not a good scene.

Yeah.

Well, and I think that comes down a lot of the times.

I mean, like that initial project with a new client and that a project, even not even initial project, any project with any client, if you've worked with them before or not, is always going to influence your decision on whether or not you want to work with them again.

Right.

So it's like, maybe they were fine the whole time, but then lately they've just they've been sloppy or maybe they've been rude.

Like I've had clients like try to blame me for things when they obviously went in and were messing around with files and it was just like, let's just get through this project and I will not be working with you again.

Actually Amanda, you reminded me about a situation that went down five or six years ago, maybe a little bit longer.

I had a local client here in Toronto and I had a great relationship, I was doing stuff.

And then my point of contact changed and he left the job and they brought in this new woman.

And right away, she just did not like me and things went south and we ended up mutually firing each other.

In this case, I think it was a culture clash with me and the new contact point.

And I tried my best, and I'm sure that she tried her best as well, but it just didn't work out.

And in the end, we fired each other.

Well, that's good.

No, it wasn't good.

On the count of three, let's say you're fired.

This is back when I was doing Expression Engine, and a year or so after I finished working with them, I checked and they were on WordPress.

It can also end up being in that situation that the person that's the new person has their own developer they want to work with, and they're secretly just trying to bring that person in.

Sometimes that happens.

Oh, yeah.

Like from the previous job, they want to hire in the contractor that they worked with there or something.

It could be, I have no idea what went down.

Maybe that happened.

Maybe it was just we didn't like each other, and then they decided to go with WordPress because it's the most popular CMS around, and everybody knows it.

Maybe.

Everybody knows it.

So then my question for the two of you is that, do you have any advice to give the clients?

Like what advice would you give the client about when to say no to a developer?

First of all, I'm sure we've all told clients a few times, it's like if you've got a new project, talk with a couple of different developers, you know, just like trying to find a contractor for your house or someone to do yard work.

So it's like find a few different options, talk to them, see how you get along with them.

But when, how would you, what advice would you give a client when they're looking for a developer?

Look for somebody who's transparent, no hidden costs, everything's kind of upfront, and that they don't bad mouth the previous developer on their project.

So when I take over a project, I'm very careful about what I say about the previous developer.

Like I say, oh, I think I'll say something like, I think it would be better or more efficient if we do it this way.

Not saying something like, man, your previous developer sucked.

Yeah.

He's just garbage.

But you know what?

And that's because I am the previous developer in other times, and I did suck because I've grown over time.

I'm better than I was last year, and I'm better than I was five years ago.

So I don't want to bad mouth somebody.

There are a different point in their journey.

The client's no longer working with them.

I want to have a positive relationship.

Keep it positive.

Yep.

You can be negative if you have to, but you have to be really careful about how you're doing it.

Oh, they made a mistake.

Not like they, oh, they f'd up.

No, they made a mistake.

Even that, I usually try to frame it as that's not a decision I would have made.

That's good.

Yeah.

Yeah, there's ways to soften the blow and you're not attacking the previous developer who they worked with.

And maybe they still like, maybe that person got a full-time job or they quit or they just don't have the availability or maybe they don't have the skills that your new client needs.

It might be safe to badmouth them if their relationship ended up terribly, but you got to remember, if you do that, it's still going to come back and haunt you because karma, karma, karma.

I know there's no science on karma, but...

Don't burn those bridges.

It's always good to spin that in a way that you're giving the client a better option for their business.

So it's like saying, I can improve on this by doing X, Y, Z or whatever.

I think this could be done in an efficient way if we did this.

And then they just start thinking of, oh, this guy is helping me make my business better or my organization better or whatever, rather than saying, the last guy screwed this up bad.

I'll fix it.

You know what I mean?

Don't do that.

Telling their client or giving them the advantages, the benefits of what you can do for them rather than the cons of what the old guy did.

Yes, exactly.

Exactly.

So I have another thing for clients to keep an eye out for.

I think something that's probably fairly common in our industry being tech people is finding a developer who speaks too much jargon.

And we have two episodes about web jargon, and we've linked them in the show notes maybe.

But yeah, if they're trying to throw all these big terms at you and kind of confuse you and make you feel like, oh, I don't know what this guy's talking about, so I better hire him to solve whatever problem.

That's bad.

Don't do that.

A developer should be able to speak to you in plain English and explain things, to a certain extent, of course, but it should be clear communication.

The developer needs to be able to translate to the layman the technical stuff and not in a condescending way.

That's right.

It's not their job to know, so you gotta tell it to them in plain language.

So, with all of these tips now of when to say no, how?

I find that sometimes difficult too.

We already cover, you don't stand up and just throw a glass of water in their face, but how would be a good way to say, no, this isn't the project for me, or just basically, I reject you.

I just do not want to work with you.

That's what it comes down to.

I think we can hit up some relationship reddits and find answers about that.

How do you turn down a man or a woman for a date?

You know, it's the same kind of answer.

Yeah, I just say to your client, it's not you, it's me.

We have to end this.

Okay, so how about this?

In some way, especially Sean, you said earlier, maybe burnout, maybe you're just too busy to take on a project.

One way you could say no is to try to propose to the client, hey, if you really want to work with me, maybe we can take this project on next month or whenever you are able to based on your schedule.

So try to propose that they take on the project with you another time when it's more of an option assuming that none of those other red flags are there.

I think that's an excellent idea.

Another option would be to put them in contact with a mutual colleague.

So maybe I'm too busy, but I know that Amanda's a little bit slower right now or this is the kind of project that Amanda likes to work on.

All right, I'm going to say, hey, I have a colleague, talk to Amanda.

I'm sure she can help you out.

But before I tell the client that, I would reach out to Amanda to make sure that I was right.

Ask.

Yes, absolutely.

Yeah, definitely ask first.

And then I think maybe just in the most generic sense, like just have a couple of go ask Chad GPT if you need to, but have a couple of just good generic, it's not you, it's me phrases.

Yeah, I don't think that this project would be a good fit.

I don't think that my my current availability is at zero.

I just I don't have time for a project like this, like something that's, you know, not not not putting the blame.

It's outside of my skill set.

Well, I don't like admitting that.

But yeah, but something it could be like you're being asked to do something like, hey, can you make the next Facebook for me?

Clearly that's outside of my skill set.

Hey, for the right amount of money, I'll find people who have that skill set.

Yeah, the truth is that the way to say no is not to say no.

You know, you have to be polite and all the rest of it.

So yeah, that's that's a very good point is whatever you do, make sure you say it with courtesy.

Especially because you don't, I mean, maybe maybe it's just this one project.

Maybe it's just this one contact at this company, and maybe you're hoping maybe you've worked with somebody there before and you want to be contacted by that original person again.

You always want to leave that door a little bit open, maybe not for this project.

But maybe you want to be contacted again in the future.

And yeah, I guess try to include some verbiage that, you know, says that, right.

So I wanted to just throw in real quick here that one's mental health is something that I don't know if we have an episode about mental health, specifically in our industry, but it's super important because burnout does exist, imposter syndrome exists, all that kind of stuff.

And so just I would recommend that people be aware of their own mental health, whether they have time to take on a project, that kind of thing.

And how is this going to affect your regular life if you do take it on?

That might be a reason that you might consider saying no to a project here and there, just to maintain some sanity, right, in your regular life?

Yeah, definitely, definitely.

And then there's always the possibility that you have to say yes, even though you don't want to.

And that's likely due to business.

Business has been slow for a while and you want to pay the mortgage.

You want to put food on your table.

It's a tough decision, but you need to weigh the level of stress you're going to get from not paying the rent or your mortgage versus the level of stress you're going to have to deal with.

Maybe it's a difficult client.

Maybe one of the other things that we talked about.

Sometimes you just have to say yes, deal with it.

It's unfortunate.

I mean, I'm sure that all three of us have done that at one point or another.

Yep.

That's true.

It's funny that the different types of projects you've become open to depending on your availability.

I don't know about you guys, but if I have a lot of free time, suddenly it's like, oh yeah, you want me to do that?

I don't ever do that stuff, but for you, you got it.

You know what I mean?

For you, yeah.

Yeah, I'm definitely more open to stuff that I don't like when I'm slow.

If I'm fully packed, I'd be like, sorry, this is just not the right thing for me on work.

And on the other side, when I'm too busy, I'm too good for everything.

I don't take that.

I don't do that kind of work.

I'll find somebody else.

You guys are crazy.

Dear clients that are listening to this episode, Amanda will do all the work.

Anytime I have no political affiliations, I have no moral obligations.

I just, like I said, dollar signs right here over my eyes.

That's why we keep hiring you for our stuff, Sean.

That's right.

Girls, girls, get that cash.

One of the smartest things Missy Elliott ever said.

There you go.

All right.

So is that a wrap, everyone?

I think that we've covered everything.

That sounds good.

Yeah.

I think it's good.

Excellent.

Thank you.

Thank you, guys, for coming up with this topic.

First episode of the season.

There will be many more.

And be sure to check us out on YouTube as well.

We have a YouTube channel every Second Wednesday at 1130 thereabouts.

We do Lunch Bites where we get deep into the issues there.

It's very casual, but it's fun.

So check it out.

It's definitely fun.

Okay.

Thank you for listening.

Talk to you guys next time.

Goodbye, everyone.

The Website 101 Podcast is hosted by me, Amanda Lutz.

You can also find me online at amandaluz.com.

Recording from a secret lair while plotting world domination, I'm Sean Smith, your cohost.

One of your hosts today was me, Mike Mella.

Find me online at belikewater.ca or on socials at Mike Mella.

I feel like we need a more graceful way to end.

Yeah, especially these ones where we come back from nothing.

We haven't done it in a while.

It's like, how do we end this thing?

Just wait for the conversation to awkwardly peter out.