Why Assembling Freelancers Kills Web Projects

The Reservoir Dogs Problem

I had an interesting experience with core web vitals today that sent me down a rabbit hole I wasn't expecting. I've been deep in Lighthouse scores lately, really locking in on the technical side of building websites that actually perform on the web. But before I get into the performance stuff, I need to talk about something I've seen destroy projects over and over again: the way most people assemble their web teams.

Here's what happens. You hire a bunch of individual freelancers who all specialize in different things. You put them in contact with each other. They've never worked together before. Nobody knows anything about anybody else. It's like Reservoir Dogs. Nobody knows anybody, so nobody wants to back down.

But forget the ego thing for a second. Let's say everyone is totally chill, no major ego battles, everyone is competent, everyone works well with a team. It's still a bad idea to have a designer design an entire website to completion, then hand it to a front-end developer to code out to completion, then launch it, then bring in somebody to handle SEO, content publishing, social media. Even in the best case scenario, this process is broken.

What Happens When the Designer Is an Artist

The designer wants to make a name for themselves. They want to impress you. They want to do something novel, something that really stands out, something that signals serious design skills. They're basically artists expressing themselves. They want you to see something you can't get anywhere else.

This is a nightmare for the front-end developer. You're trying to plan all the typographies, plan all the components, be as efficient as possible because you know your time is probably the most costly time being billed. You quoted them a budget based on how many pages and what features they described. Then you get the designs and everything is different. Not just different from every other website. Every page has nuances. Every section, every content block has this little flair of attitude that sets it apart from the others.

I'm not talking about a website that looks bad. I'm saying a website that looks phenomenal. Part of what makes it look great is that extra little flair while tying it all together. It all looks like it belongs together, but every little thing has some kind of nuance about it. And the developer is sitting there thinking: every bit of this has to be its own separate component. I can't reuse any of this. You're using this typography here, but then it's just a little different over here. It looks stellar, but even speaking objectively, it's ten times as much work. It's going to take ten times as long. It's going to cost substantially more.

The Startup That Burned Cash Until It Died

I worked with this really cool dude once. He was fun to work with, full of energy and excitement. Because of his personal situation, what he had invested in terms of money and relationships into this project, it broke my heart to be honest with him. It was like having a family member with a drug addiction begging you for money, except I was doing that with my time. He really needed to believe this was going to work because of personal relationships tied to his business and his own savings he'd poured into this website.

The setup was the classic disaster. A bunch of people from different backgrounds, all working on the same project as freelancers. Freelance designer, freelance front-end developers, none of us knew each other. The designer came in and designed the entire website. Once the stakeholders approved it, those designs became rigid. We had to make it look exactly like that.

On top of that, the front-end team had a hard requirement to use a specific framework. I'm pretty sure it was Material Design. The designer was bringing designs that customized every little thing. So you had to build on top of Material Design elements while fighting the way Material Design wanted things to look, but the stakeholders had already approved the custom designs. The designer didn't like us changing his work. The stakeholders didn't like it either. "No, no, no. We approved that design. We thought it looked really cool. Make it look like that."

And my poor guy was stuck paying my tab. I kept telling him I couldn't promise I could do it for the quoted amount. If the front-end lead felt I didn't follow the Material Design patterns, they'd reject the pull request. If I changed the design to follow the framework, the designer would raise hell and the stakeholders wouldn't approve it. Stuck in a loop, just burning cash.

I finally had to tell him: this is over. I have to stop you from continuing to burn cash. Thankfully he didn't give me a bad review, because a lot of people would have taken that out on me. To this day, I'm disappointed he's not in my network anymore. Whatever was going on in his personal life was banking on that opportunity working out. I've never heard from him again. I should probably reach out and make sure he's okay.

How Do You Protect Yourself as a Freelancer?

I protected myself in that situation because I'd been there so many times before. Usually what I can do is just eat the extra time, work off the clock, bang it out, get it done, clean break as soon as possible. Sometimes that's enough to save the relationship. Sometimes it even transitions a fixed-price job into an hourly engagement.

That lesson was learned from prior experiences where I stood on principle and got nuked in the reviews, took an income hit. Some people are real hard asses. They'll try to squeeze a refund out of you. I've given partial refunds. Never a full refund. Usually when people ask for a full refund, they're willing to accept a partial. It's a sales tactic. They say full refund, you talk them down to meeting in the middle somewhere. At the risk of giving away the game to all you young freelancers out there: sometimes it's better to give a refund than to have your reputation nuked. You can't put a price on how much money you'll lose from one nasty review at the top. You're going to have a hundred great reviews and people are looking for that one bad review. That's what they're going to care about.

More Science Than I Ever Expected

I actually wanted to talk about Lighthouse scores and technical web performance, and I got sidetracked. But it connects. I'm learning so much about the technical side of digital marketing, and it's actually a relief that there's so much depth here. I was worried digital marketing was going to be a few simple technical things anyone can learn quickly, and then mostly subjective hoodoo about getting inside people's thoughts and feelings. More art than science. I'm relieved there's way more science to it than I ever thought.

Part of me wishes I'd done a deep dive into this stuff earlier in my career, but I'm glad it worked out this way. I like being able to come at this confidently as a competent engineer. There is a "woo woo" side to it. The marketing aspect is real. You have to understand your brand, understand your market, develop a voice, know how to speak to your target audience. There's science to measuring the impact, but you still have to seed the creativity and build the intuition.

The more I think about it, this is the perfect field to get into as a human in a space where AI is transforming everything. What I'm describing is a field that transitions gracefully into AI augmentation without taking the human out of the loop.

Why Engineering Skills Change the Game

Because I went the VC-funded SaaS startup route, I have real engineering skills. So while I'm learning to be an elite competitive digital marketing firm, when it comes to the subjective stuff like brand building and actual marketing, I can focus energy there. That's my main blind spot. And whenever there's a technical aspect, I can tackle it with confidence. We need this meta on this page, we need to pull this data from this API, transform it and interpret it. Web servers, the React framework, how browsers work, what renders client-side versus server-side, painting and hydration. Every time something explains a technical concept, I don't have to do a deep dive. It just immediately clicks.

As soon as I locked in on Lighthouse scores, especially with Claude helping and all my automated pipelines running in the background iterating autonomously, getting scores, making updates, rerunning, with me directly engaged in improving the web vitals pipeline, I was able to within hours have a pipeline that can take a website and transform it into a high-performing site. Not barely above 90. We're talking 96-plus consistently on both desktop and mobile, safely and reliably. Now I just have that ability. And that's one relatively small piece compared to everything there is to improve. I lock that in and move on to the next thing.

Every day I'm tackling another technical aspect of this field. Every day I'm moving ahead of more people. I'm an engineer, so I'm just going to keep doing this. I'm like the Terminator in the hydraulic press, one-armed torso just crawling after Sarah Connor, one slide after another. I just don't stop. The only difference is I'm not going to get crushed. I'm going to compound all this momentum and grow.

What Does It Look Like to Do It Right?

You need a firm. A team of people who have worked together on many projects, experienced success together, experienced failure together, and tackle every project collaborating from the start. Your design person needs to be a member of your team, part of the company. As they come up with designs, they're showing the rest of the team. "Hey, front-end developer, take a look at this. What does this mean for your role?" Not just "do you like how this looks" but "what does this mean for the build?"

That developer is going to think: when we look at this page and then that page, there's so much novelty between them. If there's a way to start standardizing these elements, that helps me be more efficient coding and maintaining the code. Then you talk to the performance expert and they say: yeah, that looks really cool, except you've got so much JavaScript on the screen that I'm going to be fighting to get Google to consider us a good site. Maybe if we could tone down some of this animation, or break these sections apart so we can lazy load them. You can have these conversations early on.

Then the real kicker. You build a beautiful website, coded flawlessly, hitting your performance metrics. And the person in charge of your marketing campaigns looks at it and says: I can't figure out how to make a call to action work here. This isn't consistent with what the market is going to respond to. Now imagine you'd designed the entire website to completion, paid ten times over for a front-end developer to customize every non-standardized element, fine-tuned performance, and then your ad campaign manager and social media copywriter come in and say you need to get rid of most of this. They start asking you to delete parts and completely rebuild others.

It needs to be a team effort from start to finish. They need to be familiar with each other, used to working together, collaborating early. Every time you design, execute, and launch a call to action, it needs to be directly aligned with your ad campaign and social campaign. You need to be gathering data on these campaigns, AB testing, finding out which version gets the clicks. There's so much more science behind this stuff than I ever imagined, and it's exciting because I can develop the traditional marketing skills without having one hand tied behind my back on the technical side. Going the engineer route first means I can build momentum fast. I'm instantly valuable with technical site quality, performance, data gathering, and analysis. The features and functionality at this stage are a piece of cake. And as the complexity grows, I'll be ready for it. There are so many hard lessons I've already learned in software development that I just get to apply now.