5 Mistakes I Made Working with my First $170M+ Yearly Revenue WordPress Client
Look – I’m going to be honest with you – I had gotten used to working with small and medium sized businesses. As a WordPress developer (and SEO guy) – I would take over a client’s site – I would setup a staging site and then fix up things one by one. The client was happy with my work – they would email me any fixes or changes they needed – I would then do those changes – and they would see that it’s good and everyone would walk away happy.
During this time I also worked for big companies – but mostly in contract work or on small side project. For example I worked with one of the biggest grocery chains in Australia to set them up with a minisite – and while that was great I was still working on behalf of an employee for the company and my access was limited – I was basically the hired help that was asked to complete some last minute changes and then sent on my way.
That was until I got my first $170M yearly revenue client. Actually this client couldn’t have come at a better time. It was the start of Coronavirus and my clients were dropping like flies – and this client was in the online gambling industry – an industry that saw no decline during Corona and actually started booming. And not only that but I wasn’t just responsible for setting up some minor things but actually for the entire front end facing section of the site. It was a great project.
However – dealing with a bigger client presented some unique challenges – my hope is that this gives aspiring WordPress developers who are looking to work with bigger clients some insight on what skills they should pursue should they come up against this challenge in the future.
So let’s get started.
Mistake #1: Not knowing how to do atomic commits in GitHub
Here’s the thing – if you start working with a large company – especially a technology company there is a high chance they have a revision repository with GitHub. This allows them to track their code – super large companies don’t like you just coming in and being able to change their site willy nilly.
Which means that you’ll have to setup your own Git repository and then create a pull request for the client’s dev team who can then review your code and approve it to be pushed to a staging site (from where they’ll test and push it to live).
Now learning Git is no easy task – and even when you learn enough creating commits that will get passed through is no easy feat either.
And it’s not just a matter of how clean your code is – creating pull requests – I thought – was just pushing my code to their repository to show what I’ve done – but many times the dev team will want an atomic commit of everything you’ve done – which means every pull request should only have one commit.
Creating multiple pull requests and having code organised in such a way is a drag – and is something you may want to look into learning. Just create a GitHub repository on one account and have your own Git repository on another account and practice creating multiple pull requests for the information required. It’ll make your life a lot easier when devs ask you to re-arrange pull requests and generally mess you around in GitHub.
Mistake #2: Using Docker
Docker is the new big thing at the moment and has replaced MAMP for many high level projects when setting up a local WordPress installation is required. Docker basically allows you to run phpMyAdmin and PHP on your local Mac/Windows environment.
Personally I found Docker too slow on my Mac – (and I am not the only one). However to satisfy the client the best thing to do is to go through the proccess of setting up Docker on your local machine – as you will need to in order to setup the database (which Docker will compile for you). Once this is done however I found working on Docker way too slow.
Instead what I did was installed phpMyAdmin through Docker – downloaded the database and moved the files over to my remote server. This also fixed another issue – a client will request something done quick and you have to submit a pull request to have it approved to show on a site that the client can actually see.
By moving the site to a remote server (away from Docker) – I was able to deliver results to the client fast – by showing them a live version of the site. The best thing about this was once the client approved I could push the code and if there were any delays it would not reflect badly on me.
Mistake #3: Not knowing/integrating with SCSS (and looking silly in the proccess)
Look – I love CSS as much as the next guy but I never bothered learning SCSS. SCSS is basically a CSS compiler that allows you to create stylesheets much quicker. While you may think (like I did) that having a CSS compiler is overkill – despite what your thoughts are SCSS is an industry standard now.
Most of the time you will get client’s sites with a sass folder – which will contain the scss which will be then compiled into CSS. Stupid me went ahead and edited the CSS file directly – leading to being told like
“Hey, you do realize our SCSS compiler is just going to overwrite that CSS you placed there?”
Which of course made me feel like a moron. Learning scss and setting everything up on your local so you know how it works is going to be a great advantage – not only is SCSS cool in itself – it will make you look like you play with the big boys.
YOu can get away with not knowing scss with smaller companies – but once you start working with bigger clients you’ll need all the help you can get.
Mistake #4: Understanding staging precedence
With bigger clients you will many times be working with more than one staging site – making sure you understand exactly how a build gets put online is really important. For example I edited pages on the pre-live site instead of the pre-staging-live site – which caused issues and slowed down development. Ideally you want to sit down with the developers and go through the process of how a site gets pushed live – exactly what is involved and what technologies are used.
The best thing about this is – if they mention a technology you’re not familiar with you can take notes and get yourself up to speed.
This is something I didn’t do from the beginning and caused some confusion up front.
—-
Hopefully this list gives you some insight into working with larger companies as a WordPress developer – this is of coruse just one company however I am writing my experiences so that future generations can hopefully get something out of my experience.
If you have any questions about this post or any other WordPress topic simply head over to my website – I’m a Head Studios web development – and fill out the contact form and I can get back to you. I work with clients such as dimockslaw.com.au and others in the cosmetic industry. Thanks for reading!
ABOUT THE AUTHOR
