Freelance Fears of a Junior Dev

I was excited, if a little apprehensive, when E. asked me to build him a website. A close friend of my girlfriend's, E. was the most stylish person I knew. He was a multitalented artist with an innate sense of impeccable design that some people are just lucky enough to be born with.

He needed a web site that served not only as a portfolio, but also as a portal through which his supporters could donate to his current projects.

And he needed it done in a week.

I had a few reasons to be nervous about taking the job:

1. I knew he knew my design instincts weren't as, let's say, intuitive as his. I'm a photographer, and I have opinions about what looks nice and what doesn't, but I was worried that what I designed for him just wouldn't cut it.
2. I also knew he also knew that I had recently graduated from a coding bootcamp and that this would be my first freelance project. (What he may not have known, I now realize, is that the skills taught in coding bootcamps aren't necessarily the same as a self-taught developer. If the organic autodidactic path to software development typically goes through HTML, CSS, and JavaScript, with a nice holiday in Wordpress, and then on to brighter and more code-heavy pastures, my bootcamp was a bullet-train to database design and refactoring for Redux. As I've written about previously, there are some gaps in the bootcamp skillset that E. probably wasn't aware of.)
3. Inexperienced as I was, it was difficult to settle on a rate that was fair to everyone. We didn't really discuss a budget, and of course I was going to be charging him less than a client off the street, but I also didn't want to insult the both of us with a laughably low rate. But then, like I said, I didn't have a sense of his web-design budget.

I was worried that, should anything go wrong, a professional disagreement could put a strain on our friendship.

Despite my reservations, I accepted the gig. I find fulfillment in solving problems and being of service, so I was happy for the opportunity to help my friend. E. had a lot of visually stunning images for me to work with, so I was excited about the idea of adding a beautiful project to my portfolio. And as a job-seeking bootcamp grad, I was eager to get more experience under my belt.

E. came over (we're in a covid pod) and showed me a Squarespace site he had quickly mocked up. He told me that he'd found the platform to be a bit much, and with no web design experience of his own, he wanted to bring a--and I can't stress enough how difficult it is for me to use this word--professional into the mix.

I asked him what design elements on the Squarespace site were intentional and which were sort of boilerplate / accidental Squarespace designs. He told me what he liked, what he didn't like, and what was important to him in terms of design and functionality. I thought we both came away from the meeting with a sense of mutual understanding, which made it all the more painful when he asked me, less than a week later, to disconnect his domain from the site I had built so he could move forward with the original Squarespace version. He disliked what I'd done so much that he was willing to go back to square(space) one (sorry) rather than continue to work with me. I was crushed.

Now that I have some distance from the situation, here's what I've learned:

Mistakes Were Made

Yeah, no duh. A lot of these might be obvious, but they weren't to me at the time, and it's important to admit when you fucked up.

Here's what I did wrong with E.:

1. We didn't discuss budget.
   • This one's gotta be top of the list. Never again will I agree to a rate without knowing what that money means to my client, no matter what the "going rate" is.
   1a. I shouldn't have charged by the hour. As a junior developer, it takes me longer than more experienced engineers to complete a project, especially when there are new technologies involved. My client shouldn't have to pay for my inexperience.
2. I researched poorly.
   • If I had really thought about it, I could've guessed that the most complex part of the build would be processing donations. I should've researched presented him with a list of options based on what mountain climbers would call the "crux," or most challenging part, of the project.
   • This resulted in an unpleasant surprise for my client when I told him, uncomfortably close to the deadline, that despite having paid me to build his site, he'd still have to pay up to $30/month (depending on the platform and implementation) to process donations.
3. I prioritized the wrong things.
   • E. had told me that his priorities were
     1. design: interactive javascript / moving images
     2. functionality: as previously stated, processing money
   • Despite those instructions, I focused on setting up a robust CMS; I implemented interactive scrolling but very built very little interactivity into the imagery; and I left the donations feature to the end of the design process.
4. In short, I didn't prioritize the client's needs.

Lessons Were Learned

Here's what I'm going to different moving forward:

1. Obviously: *always* **always** ***ALWAYS*** discuss budget before taking a project.
2. Until I learn to work more quickly, I'm going to charge a daily rate instead of an hourly one. If I'm going to go down a rabbit hole learning some new frontend framework or markup syntax, that shouldn't come out of the client's pocket.
3. Measure twice, cut once. I've never been good at this, but now that other people's time, money, and intellectual property / branding are on the line, it's important that I approach each project with a 360° view of what the project needs to be completed.
4. Approach each project as a person, not just a web developer. If I had really thought about it, I mean *really* thought about it (and, you know, learned about it), I **absolutely** would've told E., "I think you should just go with Squarespace. I'd be happy to help." Maybe I would've charged a consulting fee, or accepted something other than cash in exchange for helping a friend. Who knows. But approaching problems holistically, with the client's priorities at mind, is a big goal of mine going forward.

In the end, I made a donation to E.'s project——something I was going to do anyway, and not in the form of a full refund, but enough to say, "Hey buddy, I'm sorry I fucked up. I appreciate you paying me for my time and my work, but this was my bad." And the thing is, I was happy with the site I built! It was responsive, it looked great, and the CMS functionality was really exciting. It just wasn't what the client needed.

Luckily I've got another freelance gig on the horizon, a project on which I look forward to implementing these new insights. When it's done, it'll be up on my website. I'm still a job-seeking bootcamp grad, but a little less green than I was when I graduated.

Comments

[CoderSales.io]

Good story... and good learning experience. You touched on a very important topic which is ALWAYS qualify your prospect. You must discuss budget/decision-maker/timing/need(s) for your own sanity. A good line I use is "Ok, I'm going to make you a great website BUT first let's get the $$ out of the way. What are you wanting to invest in this whole project?" Then, in my experience the prospect is usually open to 20% higher project fee if you can hit their hot button and show more value. Keep learning and asking good questions during your prospect meetings and you'll begin to close clients. Happy hunting!

[Jacob Fromm]

Thank you! This is great advice that I look forward to implementing as with future clients.