How to Crush Your Next Website Project from Start to Launch with Blake Imeson from LimeCuda

Foreign.

Welcome to Inbound Agency Journey. This is the show where inbound agency leaders share the strategies, shortcomings, and successes they've experienced in their journey toward building their dream agency. Now here are your hosts, Andrew and Gray. Welcome to this week's episode of Inbound Agency Journey. This week, in a rare part two, I'm bringing back on Blake Imason, who's on podcast last week where we talked about his story from starting his agency, Lime Kuda. A lot of the lessons that he's learned along the way, the pivots in that entrepreneurial journey. And Blake, I wanted to bring you back on this week to really dive into what you guys do best, which is the web design development process. That's one of the big pillars of the agency and one of the things that you guys are known for. So welcome back on. Thanks for being willing to come on for part two.

Appreciate it, Gray. Glad to be back.

Yeah. So let's, let's not. We won't waste too much time here. We'll go ahead and jump right into it. So we talked last time, we talked about sales, a good amount, too, and what the process looks like to bring a client in. But I kind of want to walk through just step by step, the web development process for a client. If someone comes to you and they're building out a site and if there's any, there might be some stage setting that needs to happen here with what a typical site or project looks like, but give us a sense for what the workflow looks like. And I'll interrupt you, I'm sure, with a lot of questions, but how do things get started? And then I've got questions about typical timeline, all that kind of stuff. But how do things get started?

Yeah. So, you know, the way things start would be pretty typical for every project where there's, you know, kind of like a discovery phase where you're trying to figure out what does it have to look like. And we try and spend as much time just listening at this point and, you know, asking probing questions because it's pretty rare that the client actually knows what they, what they really need, that they have some idea about what they want. But usually it's just kind of what they picked up in their industry or what seems to be kind of buzzwords or whatever. So they might be like, hey, yeah, we totally need a blog. They may, or they may be fixated on some certain feature. So we try and spend a lot of time in that discovery phase, kind of capturing what is the best way for this whole Thing to be structured, and I'd say kind of pulling back another couple thousand feet over time. We've tried as much as possible to create a kind of a process where these are the things we do step by step. But also we've had to realize that that's got to be kind of malleable too. Like, you have to be fluid with that because it's pretty rare that we have two projects that look exactly the same, you know, have exactly the same kind of client team and needs. So we've tried to be rigid with our structure where we can and flexible where it's helpful. And I think that's worked out really well just in terms of our thinking about the project, that the design process and the structures we put in place, if they're not working towards the thing being an amazing project and, you know, having great results, then it's kind of defeating the purpose of them.

Right, that makes sense. Blake, on. On a lot of the projects that you guys are doing on the website, are you almost always doing the design piece as well as the development, or is it pretty common to have someone come to you with designs and you handle the development side of things or vice versa?

Yeah, so I'd say probably 50% of the time we are generating the designs internally. You know, part of a. Part of our team is crafting the specific design 25% of the. Or maybe like 20% of the time it's someone on the client team that's at least setting a lot of like the design vocabulary and just basic structure that we might then take and actually create the design from. And then the remaining like 30%, which is really a great fit, is when like a marketing or branding agency comes to us and they might have the client relationship and they'll even generate the design because they know exactly what they're shooting for. They may be doing some offline stuff, some print stuff. And so 30% of the time probably we're working with an agency that's giving us a design or at least a pretty good kind of like mock up that we can then turn into a website.

Yep, that makes sense. Cool. So you talked about the consistent discovery phase and doing as much probing there as possible. And we talked about how a lot of that is happening in a lot of cases kind of pre sale. But I'm sure there's some of that happening post sale. As you're kicking off the project. You have the signed contract, you have a production deposit or whatever that initial payment is. Do you guys host like a big project kickoff call or do you go meet them in person? Do you get everybody on the phone at the same time, what's happening? Kind of. I guess that this might be helpful too is what are the mediums that the conversations are happening in? Is it phone call, online meeting, email? What's the setup?

Yeah, so usually we do have kind of a project kickoff meeting. Rare that we'll be on site. Maybe 1 out of 20 projects or something will actually fly to where the client is or drive there. A lot of our clients are kind of spread out over the US and further, so it doesn't always make sense. It's not always efficient. So usually that ends up being a phone call. And we'll try and get as much of their team on as as needs to be on and just kind of talk through the project, start to get excited about it, identify who's doing what, you know, try and figure out what are all the different roles and who are the kind of key people that will be chasing things for us from them, who are the key people who are approving. And, you know, we'll talk about timeline at that point as well. But usually that is just like a phone conference call.

Okay, yeah, that makes a lot of sense. I think that's how a lot of people do it. That's how we handle a lot of our projects as well and try and get as many people on that. What does. And I realize it's going to be a little bit project specific, but are you typically then moving right into design? And probably on the client side they have some homework around getting some content or assets over to you. What's the next phase out of that kickoff meeting?

Sure, sure. So we kind of also divide the project into three parts and how we think about it. And all three, of course, interlap or, sorry, overlap. And all three could be something we attack at the same time. So those three would be the content, which of course could be the actual words, the actual imagery, maybe even video, then the actual design. Sometimes there's like a rebrand component of this or, you know, refreshing the typography or the color palette. So first one is content, second one's design, and then third one would be just development, which is kind of like. We think of that as like functionality. What are the moving pieces of this? You know, is it going to have a blog, is it going to have a calendar, what kind of forms and CRM integration. So we divided up in our minds in terms of content design and development, and depending on the project, we might be pushing on all three of those at the same time, because there does hit a point where they kind of all nicely converge together. In an ideal world, there might be a bit more of a kind of breathing room. And you know, you do the content and the content might be all done before you even start the product. That'd be lovely. Then you might do design and take that content and make sure it, you know, fits into a design that fits the brand and is effective. And then you might take all that design work and then actually code it up. So that's kind of philosophically how we think about the next phase. The actual, like doing part of the project.

Are you typically. Because for us, like a lot of those things, typically content, in a lot of cases, the client's pretty involved with that. But we'll kind of, that'll get started right from the very beginning. A lot of times there's some SEO, there's some research and SEO work being done, I guess just kind of groundwork being laid and then the content side is being handled and then we'll jump right into design. And then development is not really the last piece, but it's kind of the last piece before the implementation of the content. So content is kind of the first and the last.

Sure.

Makes sense when we're doing that. But how, like, are you guys spending a week, two weeks just focused on content, or are you doing content and design at the same time? What. Or is it just different people handling that throughout the process? What's typical? I guess let's. Maybe this, what would help this process out is if we just take a. And if this isn't typical for the type of projects that you guys are doing, just ignore that. But let's say the client is giving you, they're going to do most of the copywriting. You guys might do some touch up and a little bit of SEO for them, but you don't have to create the content. You're pretty much just implementing it and making it look good on the site and then you're responsible for design and development. So in that case, what does. Like, are you guys diving in and doing design and assigning out some content work to them? Or what is that kind of, what does that piece look like and how do you structure that and handle that?

Sure, sure. So probably a good bit of the time the client is, you know, of course doing most of the content writing or rewriting and we'll try and give tips and give some kind of guidelines for how to do it. Other times they'll bring in like, or we'll bring in like a subcontracted copywriter. Oftentimes this needs to be someone that you know, specializes in their industry or at least knows the vocabulary. Then the third situation would be that, you know, that the agency is responsible, like a branding or marketing agency is responsible for the content generation. And rewriting the content will be written ahead of when we actually design the page. So usually we try and design the page to fit the content. You know, what specific stuff will be in what sections, where's video go, how's it kind of structured? Is there a call to action at the end? And sometimes there's got to be some back and forth because once you start putting the content actually into a real live page, you know, it's rare that it's exactly effective the first time. So sometimes it's bouncing back and forth, iterating on both what the content is and then how the page is structured or laid out.

Right, that makes sense. So if you're doing design based on content that you have, and content typically doesn't come all at once, is there a lot of. Well, let me ask this specifically about the design process, I guess. Is it typical for you guys to have the entire site or all the designs that you're going to do, at least for the site, done before you start development? Or is it more of kind of the agile sprint cycles where you're doing design, then you're implementing that as the next design is being worked on? Is there a typical way that you guys do that?

Sure, yeah. So really small projects we might jump straight into kind of like designing in dev. These would be like real low budget projects where the client's not really interested in a custom design. So it's possible that for a small number of projects we do that kind of like agile design in the browser type thing. We're doing less of that as time goes on, as projects get bigger, it's hard to do that and stay top of, top of the design game and brand compliance. So usually we have most of what we would call the views of the site mocked up. This might not be every layout of the site, it might not represent every page, but it's at least enough of the views that we can get approval on it and then begin design on that. And then those views kind of drive all, all the other parts of the site as it comes together. So the typical views might be a home page, a service page, an about page, maybe a blog page, if there's some special features that they've got some kind of special carousel or testimonial area that might be part of it. But as much as possible we try and get the design kind of locked in ahead of time. Dev, so we don't have to keep spinning around in circles with development and design adjustments.

Right, that makes sense. What tools are you using for that, Blake? For the design piece?

Sure, sure. We've actually had a big pivot in the last six months. Have you heard of a tool called Figma?

Yep.

Yeah. So if anyone's listening and not familiar, it's kind of like Sketch, but more collaborative. It's got a lot of the same kind of ideas and components. It's very easy to use, intuitive program for creating all kinds of design. But we're using it primarily for mock ups. So the thing that we started using it and it didn't really, we thought it was kind of gimmicky at first was this collaborative aspect where we can have three or four members of our team all looking at a mock up. We can see where the cursors are and we can even be moving stuff around and seeing it happen in real time. So sometimes we'll get to a point where after the kind of design owner, the main person responsible for the design has gotten it to a certain point, we might talk about things as a team and we can see each other moving things around and it's just this great kind of like snowball effect of you see someone moving something and you know where they're going with it and you see what they're assembling and you might start doing something similar in another area. It just kind of all merges into a unified design with a couple people having input. Now that of course wouldn't work with every team and design by committee would certainly be a danger. But the mix of people we've got right now, there's very little ego in it and we're all quite open to kind of the design process being that kind of we're all in there in the kitchen together trying to shoot for the best thing. So Figma has been a really great new design tool for us with especially the mock up phase of the project.

Wow, that's awesome. Cool. I haven't talked to a lot of people who are using it yet and we're not currently using it right now either, but have played around with it before and it seems like it could be really powerful, especially in the type of setup that you guys have.

Yeah, absolutely.

So once you get kind of the design pieces, you get approval there, then I'm assuming you're rolling into development and as you're going through the development process, do you guys kind of believe in the wait till everything's pretty much built out before taking it to the client or are you doing again, kind of the same thing with Sprints where you're building out functionality, bringing it to the client and they're looking at it kind of as you're going through it. And then I guess the secondary question, the main follow up question there is if they are seeing it kind of on an ongoing basis, then are they giving approval at that point or are they just seeing that just so they're updated and in the loop and then saving that all for kind of batches of feedback at the end? How do you guys handle the development and implementation and feedback process?

Sure, sure. Before I address that, one quick note on kind of when we, when we get to the point of the mock ups being solid, that's a pretty critical part of the approval process for us. And we do a lot of kind of setting of expectations and making sure that they know their place and they know what they've hired us to do. So if as we're presenting a mock up, we try and really hammer out the hammer down the idea that they've hired us as the experts to, you know, here's what we are convinced is the best for you and it may not be what you and your personal biases each like, but is this brand compliant and will it help you get, you know, more customers or more engagement or whatever the strategic part is? So we try and really spend a lot of time setting up ourselves as like the experts and then making sure they're focused on the. The end goal is for this to be a site that reflects who they are as a company and is, you know, a strategic big step forward. And as much time as we've kind of spent talking that philosophy with them, I think it's really paid off where we don't have as much people trying to insert their own opinion or, you know, be pushy with their own biases. So that makes sense. You want me to move on to the dev?

Yeah, I think that framework makes a lot of sense and it's super important just to kind of reiterate that that's super important to have as early in the process as possible because then when it comes down to you don't want to try and address that. It's just like with anything else, you want to be harder. Just like with parenting or whatever else, it's always easier to let up later on than try and put the toothpaste back in the tube, down the road. So if you can establish that during the design process and preferably even earlier, start that during the sales process. Then when you get to the feedback and revisions phase, everything kind of goes back to why we made the decisions that we made during the design process. So just because you don't like something that you see now, it's not about you, it's about the end user. And that's why this was built out to begin with. So I think that rationale sets you up for success down the road. And that's a really good point.

Yeah, fantastic point there as well, about making that known early. And if you do that, like in the proposal kind of phase, and they see that you're really wanting them to trust you as an expert and not be the one that, you know is responsible for coming up with everything or, you know, giving you deep, detailed feedback that you're expecting them to trust, it'll some people, it'll give them a great sense of relief because the responsibilities been placed on you and the other people who would want to be in that kind of like, hey, code monkey, do this and do that and very directive, they'll start to get the sense that it's not a great fit and they might just, you know, exit right there, which is the best thing. If you can scare those people away before you're getting into a design battle, that's a beautiful thing. Do it.

Cool. So let's talk about the development process now, what that looks like. How are you guys handling that in the feedback loop?

Sure, sure. So it depends on the client, how early we'll show them. Like a staging site where the design is coming to life. If the client seems kind of real mature about it and can kind of handle being given that and won't be too quickly judging or seeing little things and really starting to gum up the process, we will give them access to that pretty early on. Others will wait until it's like, you know, 90, 95% done. And then we'll also set up, you know, these are the pages and the aspects that are done. These are the ones that aren't. So if they're the type that's really anxious to give feedback, they're not giving feedback needlessly for things that we've already got 20 issues for in GitHub that we're tracking. So sometimes it's immediately in the staging process or pretty early. Other times it would be close to the end when it's a pretty dang workable site that's Nearing launch, right?

Yeah. Knowing the client and knowing when you need to protect them from themselves in order to get something done on time is definitely a skill that you develop over time. So that makes sense.

Yeah.

I guess another question about the development process is as, say you're getting certain views or templates developed, are you working on any content implementation during that time, or do you kind of save that until most of the functionality is done with dummy content or placeholder stuff and then you're going in and implementing all that content at the end? Do you have a typical way that you approach that? I'm sure that's kind of a little bit of a project by project variance, maybe, but what's the preferred model?

Our preferred model, and this may not be the best one that's been working for us, is to pull real content into the site as early as possible. So if it's a WordPress site that they're moving from, and of course that's our platform, we might even be starting our staging site with all their existing content, knowing that it'll get rewritten and reshaped and some things go away. But if possible, we like to start with real content. A good example would be for their blog or for an events calendar, if it's actual things that they've been doing. That means that we're not designing and developing to kind of like, best case, you know, pie in the sky type of a situation. We have to then design and develop to accommodate their content, their styles and all. So, you know, if they end up doing titles that are, you know, 20 words long, we either need to accommodate that with how we're building the thing, or we need to, you know, help them address that. But either way, we. We hit those kind of friction points earlier if we're actually using real world content. So that'd be our preferred approach.

Yeah, that makes sense. So once you get that in, and I totally agree with you, the more that you can get that and understand how they've actually been using, if there was something preexisting how they actually use that so that you don't just design it based on what you know is the right thing to do, but you're actually building stuff out and finding solutions for the way that they may have done it, even if that's not technically the right way to do it. Page titles is a great example. Or if you've got folks who like to add a blog post to 11 different categories, maybe they should just do three or four tops. Then you need to adjust for all these tags that you need to show.

Right, right.

But once you get through that process, then is it rounds of feedback that you give them and then you're jumping into prelaunch testing and the launch process or how does the feedback loop work basically? And is there something standard that you're giving to? Because this is something that a lot of people. This is where scope creep, one of the main areas where scope creep becomes a big issue. Where people see it, they think, oh good, we're a week away from launch. Here's the eight new things that, well, I still have these people paid for that. I can have them do that. Maybe weren't in there. Or they just realize, hey, there really is a gap here that we didn't accommodate for before. It's not always irrational. A lot of times it is. It does make sense and it's not a bad idea. But it might be something extra or they just ask for revisions on everything. And obviously the more you curb that earlier, the better. But how do you guys structure that? And are there any tips that you have for people on the feedback loop here near the end of the project?

Yep, yep. So we of course try and push them to do their feedback in batches or kind of rounds of revision. This is one of these cases like you were talking about. You know, you start off strong and then it's easy to let off. Where, you know, with the proposal we might say, you know, we're doing two rep, two rounds of design revision. And then, you know, maybe we end up doing like two big rounds and two small rounds or something like that. But at that point it's, it's our preference or our choice to let up. And so at the kind of development part of the project where they're looking at a dev site, we try and get them to collect their feedback and send it in batches that we can address not three times a day each day for two weeks because then we have to kind of synthesize all that. That's a big. So especially if they've got a team of people giving feedback, we'll try and have some way like Google Doc or everyone send their email by this day at a certain time and try and batch it with these projects. Also we have a, with bigger projects, we usually have a standing weekly kind of touch point call where, you know, it might be every Wednesday at 10am and you know, our team gets on, their team gets on. Sometimes those are short, like 10, 15 minute, just, hey, how you doing? Things are good. You won't hear much from us this week. Or, you know, nose, nose down to the grindstone and content or, you know, whatever. But other times it might be 45 minutes to an hour of hashing out things that are coming out or questions that we have as we're developing or feeding in the content. So the kind of weekly touch points also give a chance for them to air concerns or thoughts. And, you know, if there starts to be the scope creep thing, I mean, scope creep is one of those things that, you know, we all struggle with it, but at the end of the day, it's all of our own faults, right? So if you have your proposals written clear enough that you can say, hey, this is out of scope, then you can say, hey, yeah, that's a great idea, but we really can't capture that in a phase one, if you want, I can get you a quote and we could think about rolling that in a week or two after launching. So that's really just a practice of maturing to the point where you're able to say no or able to take that scope creep and kind of pivot it. So it's a problem. But it's mostly a problem that's internal to us, kind of how I would.

Say that almost entirely an agency problem. It all goes down how you set expectations and then kind of stay disciplined according to the expectations that you set at the beginning and hold people to that, because if you let them start to start to move along, then you're just kind of setting yourself up for that contest of seeing how far we can, we can push the limits and.

How much we can get out of this. And I should say too, you know, extra scope requests are also a fantastic opportunity to, you know, better the relationship where oftentimes we'll know that a, a feature a client asks is really, it's an easy one. Like, this is like 15 minutes of time, not a big deal, but it's a big deal in their mind. So we'll say, hey, yeah, we'll do that. But just so you know, this is outside of scope. But hey, we're happy to accommodate. This is a great idea, no problem. And so then we haven't lost that value. Like, if we just take that, we haven't gained the value. We just do it without remarking on it. We haven't gained value, but if we say yes, we'll do it. And also this is something that we're gifting to you. It really helps strengthen relationship as well. So we do a lot of that, but we try and not let it pass without marking on, hey, this was outside of scope, but you guys have been great to work with. We're happy to accommodate.

Right? Yeah. Well, there's a whole. This is way more psychological, but there's a whole like way that you're giving value when you share that. Not only do they get to enjoy the fact that you made the edit, they also get to enjoy the fact that one of the ways I think about it is always trying to find ways and give ways for other people to win. So that's a way that they feel like they've won, that they've gotten something from you. Not necessarily. I guess that's more of a zero sum game approach to it. It's not always necessarily winning or losing. I think there's a lot of examples where it's not really like it. But not only do they get the value from having whatever it was that you implemented, but they also feel like they got more value than they paid for. Which obviously creates a good feeling in pretty much everybody.

Yeah, absolutely.

So I think that's a huge tip as well. Well, Blake, this has been really good. I've got kind of two follow up questions for you. One is around tools that you're using throughout the process. So I'm going to throw out some examples and some questions and then I'll let you kind of run with that if there's any specifics that you have that are either inside of this or outside. But for us, a lot of the content and pieces are happening inside of Google Drive. So we'll use Google Docs to gather a lot of content where we can collaborate in there. We'll use Google Sheets for like a page architecture, spreadsheet and SEO, keyword research and planning, and a bunch of different things like that we'll use. Then like once you get into design, we've already talked about some of those tools. Once we get into the development side of things, I'm curious to know what some of the tools are that you guys are using throughout the process. And you don't necessarily need to list them out, but if there's anything that you think that might be unusual or different or that people would benefit from from learning about. Is there anything like that in your workflow or what are some of the key tools in the process for you guys?

Yeah, so like, you guys, we're kind of a Google Drive Google Docs type shop and that works really well. A lot of times clients are familiar with it, so it's really easy to get feedback and comments and make edits and suggestions on things. So we love that for kind of capturing a lot of stuff, particularly with content or strategy. Let's see here. In terms of communication internally, we also jumped on the Slack bandwagon in the last year, which has been amazing. I don't know how we lived without it before because we might have 15 semi active projects and 3 to 5 really active current projects in play. And what was happening is our communication streams were all, you know, pulling together, you know, a Google Hang, Google Hangout thread that, you know, it was hard to follow which project we were talking about. And now with Slack we've got these wonderful channels for each project and we can kind of internally jump in and out of those and catch back up. So Slack's been a big one. Let's see here. In terms of development, that gets into kind of like our lead developer Josh Mallard's territory but I know he's got all kinds of stuff he uses like GitHub and I forget which ones we're on exactly. But grunt less sass, all those kind of compiler and workflow type tools. Let's see here. Trying to think what else we mentioned Figma. We use Toggle for kind of time tracking.

Okay, cool.

Yeah.

Are you ever sharing that time? Is that ever something that is client facing or is that just for internal tracking and figuring out how to become more efficient?

Pretty much just for internal. Some clients, some type of work will take those monthly reports and then build them for the time. It's usually at that point kind of a judgment call. It's usually not that exact time. Oftentimes it'll be a little bit less than that or round a certain way. We don't really get feed or pushback on kind of hourly billings. It's like they trust us and we do write by them and we're not. We try not to be too precise. I think if we gave them reports down to the minute they'd start to be, you know, treat it like that and they would start to question each minute. So we keep a pretty kind of loosey goosey game with hourly billings.

Cool. My last question, not around tools at all, but kind of around the launch process and what that looks like. And there's. We could do a whole other episode just on going through kind of pre launch and post launch testing and the actual launch process. But I've got a couple questions. One is how long does a typical launch process, Is it typically really easy? Just a simple deploy from staging to production and obviously replacing the old site and setting up redirects and handling all of that stuff or is there more that goes into it? And then are you guys, Is there a day of the week? This is something that's come up a couple times. Is there a day of the week that you like to launch on? A lot of people are like, don't launch on Friday because then if something goes wrong, no one's going to want to handle it over the weekend. Some people like only launch on Friday because then you can handle it over the weekend and no one else is there. How do you guys handle the launch process?

Yeah, yeah, this could be an entire podcast unto itself, but basically it depends on if they're an existing client and we've already been hosting them. Usually our staging site that we're working on is already tied to the live site. I mean, we could launch and it'd be a matter of minutes and no downtime. If we're moving hosts, which is typical for a new client, there can be some trouble with DNS. We've got all kinds of tricks we've learned with that and how to make sure that the DNS propagation doesn't kill it. But even, even with kind of a DNS switchover, typically like a half an hour of kind of awkward in between time to an hour of awkward in between time where, you know, people are seeing the old site and the new site and it's flipping back and forth, that would be, that would be more common. So we usually like to, depending on the client and their particular industry, we like to launch at night. Like sometimes it's 7, 8, 9, 10. I mean, sometimes we've done launches really late because they've been high enough profile that they even have people on their site at 10 o' clock at night. But we actually do like Friday night if we control all the pieces. So if we control the hosting and of course all the WordPress side of things, and especially if we control the DNS, for us, our team is usually kind of bouncing in and out on Saturdays anyways. So doing a Friday launch is safe for us because we're okay with working on Saturdays. If not, and the team's really like, hey, we can't jump in. Like, the client team would have to be part of it. Then we would do something like, you know, Thursday night launch or something like that, or even like end of day launch. Sometimes the client team really doesn't want to work at all outside of standard business hours. So we'll accommodate. I mean, it's, it's their, their ship. And if they're okay with that, then we'll go with it.

Right? That makes sense. Man, there's so, so many follow up questions that we could ask there, but going to go ahead and wrap it up for this week. Blake, thanks so much for coming on and being willing to share and be open about the process that you guys have. I'm sure obviously we mentioned this last time, but if folks have follow up questions, obviously they can check out your site@limecuda.com and we'll put all the links in the show notes. Again, but thanks so much for coming on and being willing to share and always appreciate talking to you.

Yeah, my pleasure. Thanks, Greg.