Ive been building sites in WP for a number of years, but need to organise myself better.
Ive created a mini workflow that wont be rigid, but at least gives me something to follow, be interested on your thoughts and areas of improvement to maximise efficiency and giving the best possible service:
​
1. Kickoff call with client with scoping checklist
2. Lean Proposal + ballpark costs
3. Sitemap creation and sign off
4. Choice of 3 premium WP Themes \[favouring Elementor\]
5. Brand guidelines for website \[if applicable\]
6. Create Homepage mockup and sign off with client
7. Access – domain, install WP on my hosting, add coming soon page
8. Build website / content migration if applicable
9. Test on desktop, mobile and tablet \[can we automate any of this with a testing platform?\]
10. Page speed insights pre-optimisation report
11. Optimise **–** WPRocket, Imagify, Wordfence Premium, Yoast, add to ManageWP maintenance dashboard with default configuration
12. Page speed insights post-optimisation report
13. Launch checklist > Final tasks > Launch
​
[ad_2]
1) stop using page builders.
2) you should get as many assets and stuff from your client once they agree to use your services. Sitemap and brand guidelines etc should all be the same time.
3) mockup for homepage, single page (blog) and landing page at same time. Gives you a clearer scope for design. Also less wiggle room for scope creep later.
5) don’t take a live site down until yours is ready to go live. Build on a staging domain or at worst an ip address.
6) you don’t need to show how bad the site was. Don’t show pre optimisation reports.
7)You can automate mobile and tablet responsive testing. But you should be able to knock this out fairly quickly and I have a higher confidence in a person doing this correctly.
8)I’m going to assume you’re a fairly inexperienced dev but you want to limit how many plugins you use for “optimisation”
My process is similar. The process really depends on what you want to offer. For example, I install and configure Rank Math and do proper title and meta desc for each page prior to launch. I also offer two to three homepage designs (depending on client/budget). I also don’t show any sort of pre-launch optimization reports (despite optimizing). All it does is prompts a bunch of questions which answering is more time/work. I also don’t use wordfence (but I harden wp-config, functions, and run a WAF) But the general process is similar.
Something I learned very early on… always use the same theme. Never let the client dictate the theme you use. Any decent theme can be modified to look like anything. Stick with Elementor or check out Bricks, or just get comfortable with WordPress core and blocks (with a theme you stick to) if that’s your thing… then Always, always use that. Fine tune your processes around that theme. You’ll find that you will not only speed up your workflow, but offer a more consistent quality product that is easy to manage and support.
Only other note… get in the habit of making your dev workflow account for mobile. Basically, I use CSS Grid via the ACSS framework for Bricks and have gotten in the habit of using pre-defined section templates from my arsenal or just defining my classes for each device as I go along… this makes mobile cleanup super easy in the end (20 minute sweep up).
Try generatepro lifetime lycense or bricks big improve over elementor and really worth the cost over elementor premium themes
>Ive been building sites in WP for a number of years
>Choice of 3 premium WP Themes
So you’re editing existing themes and spinning them?
Are you a developer? Do you know WP from that perspective?
Have you had any Project Management and/or Account Management experience or training?
Have you researched freelance contracting and have a starter proposal and/or statement of work template?
4. Is crap. If you’re going to offer custom sites and promise performance, you already have your toolset which can be customized to the client’s desire. That’s why they hired you.
This can be successfully done using a reputable starter theme like GeneratePress Pro, a good understanding of Gutenberg Patterns and some supplemental block plugins like Bricks, Kadence Pro, GenerateBlocks Pro, etc. Those are just a few.
7. Do not host sites unless it’s a serious contributor to your bottomline. I can see setting up a staging site to share milestones for review with the client. If not, then let them set up their own hosting plan and grant you access. Remove your obligation to pay from the equation. Become an affiliate to some reputable WP hosts and pitch those, or go with a host that does resellership on the client’s card and gives you a little scratch each month, too. Like 48 cents, but it does add up, over the course of a really long time. At least you don’t have to act as the sole support agent.
8. Get a one month subscription to BrowserStack during your testing phase (which should be happening throughout the entire procecss: Unit Testing). Bill the client for it, if applicable.
I love 10 and 11. Becareful with WP Rocket and it’s suggestions. Do the full diligence and test each performance mod one at a time. It takes longer but it’s so worth it. This also has to be done post launch or on an unpublished production server. Do install Accessibe free, prompt client to upgrade to pro. *This is where choosing an accessible theme and plugins is super important and time-saving.*
12. Understand that if the site host is shit, performance is shit. While CWV is important, if your site is loading pretty quickly at 4g, don’t kill yourself trying to get your mobile scores up. Do address the issues with render-blocking as much as you can, limit 3rd-party scripts for this reason. Host locally, if you can. Save for, Google and social tracking pixels you can do a lot but have to be careful not to bust your site.
13. Post-launch should include a 30-day bug window which would be accounted for in your contract and considered in the total price of the job.
Include limits on design revisions. I max my edits at 3. Anything beyond is hourly.
Make sure you’re able to clearly identify a “bug” vs. a “new feature request disguised as a cockroach”. Clients will try to say, “Well, I never really liked it can you just redo it this way?”
“No, My Lord. I cannot. You approved the design after 1000 revisions, thanks for that extra scratch, btw.”
Most importantly, have a good and honest line of communication with your client. We make mistakes in estimating, and try to prevent scope creep (a real Demon) all along the way.
With comms, comes a solid statement of work (contract) that is fully agreed to by both parties prior to signing. Meaning, be open to negotiation and be honest about the impact of any changes, additional requests (setting up email, 3rd party apis, etc.) and account for Admin time (answering emails, composing emails, text message conversations [cut that shit short and don’t invite it!], creating and sending invoices, etc.)
Please don’t take shortcuts on the legal stuff. We have very little recourse without the support of a solid, signed SOW.
Good Luck!