Section 5: The Building Workflow — Starter Template, Build Order, and Delivery

The starter template is a complete WordPress+Elementor install living on a subdomain you own, carrying everything project-independent: the plugin stack, WordPress settings, Elementor backend settings, site settings, the style guide, and (optionally) a few skeleton layouts — a basic homepage, contact page, menu, FAQ, zigzag. The discipline is that it stays UNSTYLED: every element connects to the style guide, so the template contains structure, not design — 'otherwise there's not much different than just buying a design template somewhere.'

Distribution is by migration plugin (All-in-One WP Migration, ~5M installs): export the whole site to a file, import it onto the new project's fresh WordPress install, which replaces that install entirely. Keep the template small — imports have upload-size ceilings, and a layouts-only template stays tiny (his: 92MB). He deliberately does NOT hand out his own template: 'I want you guys to go through all of these steps yourself.'

Four venues, one heuristic. LocalWP: free local installs, but sites sleep when your machine does, clients can't visit, and some features (WooCommerce) misbehave. InstaWP/TasteWP: a fresh install in ~20 seconds, but it expires (days), because 'these tools only exist to essentially sell you on their hosting options.' The DEFAULT: a subdomain under your own domain, on a host that gives you many (Hostinger's second tier: 100 subdomains) — develop there, then migrate the finished site onto the client's domain, wherever they host. The two special cases: a client with an EXISTING site uses their host's STAGING feature (copy → edit → one-button deploy — not available on subdomains); a brand-new company with an empty domain can be built directly on the main domain behind a coming-soon page — least work of all, no migration.

Two principles generate the order. PER-CONTAINER COMPLETION: inside each background container, run the full cycle — container, background color, padding class, widgets, content (lorem if real content is missing), alignment/positioning, styling, RESPONSIVE — before touching the next container. Never a page of half-done sections. ENERGY MANAGEMENT: 'you have the most energy in the beginning of the project,' so hard things come first.

The sequence: (1) homepage — the design-richest page, finished per container; it becomes the copy-paste source for the whole site, which is also why its responsive must be done ('then you have less responsive issues on most of your pages'); (2) header, then footer — so navigation works while you build; (3) custom post types ONE AT A TIME: create the CPT + fields, add content, then single, loops, archives — finish the whole CPT before starting the next ('easier for your mind'), and each finished CPT gives the client a visible archive link — progress they can see; (4) page templates (privacy/terms-class pages); (5) static pages, including the small CPTs that only serve them (the teams block on the about page); (6) saved templates batched at the end — slots on earlier pages deliberately LEFT OPEN for them; (7) delivery prep; (8) content filling BY THE CLIENT.

Building on an existing WordPress site is a different risk class: unknown plugins, live revenue, indexed links, other people's data. The rules: (1) BACKUP FIRST, saved to YOUR computer — 'many people forget it because they're enthusiastic'; (2) work on the host's staging feature if it exists, else migrate to your subdomain — never edit the live site; (3) clean carefully: 'don't just delete everything that you think you don't need' — a plugin you can't identify may be payments or customer data, and sometimes the client doesn't know either; (4) inventory the link structure BEFORE changes via Yoast's XML sitemap, copy the URLs out, and if links must change, use a redirection plugin (client-approved); (5) if the site runs another builder/theme, don't rip it out — build the Elementor replacements alongside and swap incrementally, 'slowly replacing each page template and see if nothing breaks'; (6) maintenance mode only when NECESSARY — the webshop case, where orders placed during a dual-site window collide invoice numbers.

Above all sits the meta-rule, told as autobiography: he took projects above his skill level, 'it only costs suffering... the clients were mad. It's not a good experience. It's not worth the money.' The professional move is refusal.

Four moves close a project. ROLES: create a fresh user for the client (never share your own login), set WordPress role to editor, then Elementor → role manager → 'access to edit content only' — in the editor the client now sees ONLY the Content tab: no styling, no advanced, no right-click, no container deletion; text and images replaceable, nothing else breakable. Admin rights only on request, with terms stated up front via the car-shop analogy: 'if you mess up something I'm gonna fix it but you're gonna pay.'

CACHING back ON — the dev-mode deactivation from chapter 4 reverses at delivery, plus optimizer plugins (his current pair: WP Meteor + an optimizer [as heard 'FastPress' — see asrCorrections]; SiteGround Optimizer on SiteGround hosting; all flagged as test-for-yourself). ANALYTICS: the Google Analytics family (MonsterInsights, ExactMetrics, Site Kit) is powerful but drags the GDPR cookie bar; he's actively testing Independent Analytics — 'GDPR compliant without having to do anything' — to ditch the banner. HANDOFF: a screen-recorded how-to video (Loom free tier, or Cmd+Shift+5 native capture uploaded UNLISTED to YouTube) — async beats a call because clients fill content on their own schedule.