As a Daniyal Ahmad WordPress developer, my focus is on building fast, well-structured WordPress sites using Elementor Pro and a lean plugin stack — not on accumulating page builders and frameworks I’ll never use consistently. I’ve been working with WordPress professionally since my early freelance career, and the vast majority of my 70+ Upwork projects have involved WordPress in some form. This page covers how I approach WordPress development, what my typical project stack looks like, and what I can and can’t do well.

My WordPress Stack

Every developer has preferences shaped by what they’ve built and broken. Here’s mine:

• Themes: Hello Elementor (for full Elementor builds), Astra (when the client needs more out-of-the-box styling control), GeneratePress (for performance-focused builds where page weight matters). I don’t use premium themes with built-in page builders that fight with Elementor.
• Page builder: Elementor Pro exclusively. I don’t use WPBakery, Divi, or the native WordPress block editor for complex layouts — mixing builders creates maintenance nightmares that always become the next developer’s problem.
• SEO: RankMath Pro. The REST API integration, the schema builder, and the on-page score interface are all better implemented than competing plugins in my experience.
• Performance: WP Rocket or LiteSpeed Cache (depending on hosting), Smush or ShortPixel for image optimisation, Cloudflare for CDN and edge caching.
• Forms: WPForms for general contact forms, Gravity Forms when conditional logic is complex or payment integration is needed.
• E-commerce: WooCommerce with Stripe and PayPal Payments. I don’t use alternative e-commerce plugins on WordPress — WooCommerce’s ecosystem and documentation depth makes other options harder to maintain.
• Security: Wordfence for firewall and malware scanning, limited plugin list, no unnecessary admin accounts. I remove placeholder themes and deactivated plugins as part of every project handover.

Elementor Design and Builds

Elementor is where I spend most of my build time. The official Elementor documentation covers every feature — I reference it frequently for newer Elementor Pro controls rather than relying on third-party guides that lag behind updates. The specific things I do well in Elementor:

• Responsive layouts that actually behave correctly at tablet breakpoints (not just desktop and mobile) — this is where a lot of Elementor builds fall apart
• Global styles and typography systems — setting up fonts, colours, and spacing as global settings so that future edits don’t require page-by-page changes
• Theme Builder for header, footer, and archive templates — so the design is consistent across post types without hardcoding into every page
• Custom CSS within Elementor for elements that need behaviour the native Elementor controls don’t provide cleanly
• Elementor popup builder for newsletter forms and lead magnets

What I don’t do in Elementor: complex custom post type builds that require Advanced Custom Fields (ACF) integration with dynamic content, or highly customised WooCommerce shop pages with product filtering — those move into custom theme development territory that’s outside my standard Elementor scope.

WooCommerce Development

My WooCommerce work covers the standard setup layer: product configuration (simple, variable, grouped products), shipping zones and rates, payment gateway integration (Stripe, PayPal, local payment methods where documentation is available), tax configuration, and basic email notification customisation.

I also handle WooCommerce + email automation integrations — connecting a WooCommerce store to Klaviyo or Mailchimp for abandoned cart recovery, post-purchase sequences, and customer winback flows. This is an underused setup that consistently delivers measurable revenue for stores with traffic.

What falls outside my WooCommerce scope: multi-vendor marketplace setups, complex subscription billing with payment failures and dunning, custom WooCommerce hooks and filters requiring PHP development beyond configuration-level changes, and WPML/multi-currency setups for international e-commerce.

WordPress and SEO Together

The overlap between WordPress development and technical SEO is where I add the most consistent value to client projects. Most WordPress sites have the same 10–15 technical SEO issues that are directly caused by the development setup: missing schema markup, no XML sitemap, robots.txt blocking the wrong things, page speed problems from unoptimised images and plugin bloat, and internal link structures that create crawl inefficiency.

When I build or rebuild a WordPress site, I set up the SEO fundamentals as part of the project — not as an afterthought. This means RankMath configured correctly, a clean sitemap submitted to Google Search Console, properly configured robots.txt, and a site structure that lets Googlebot discover all important pages within two to three clicks from the homepage.

For an in-depth look at the technical SEO side of my work, the technical SEO audit guide covers the full process I use when reviewing a site’s technical health. And for the WordPress-specific security layer that often gets missed, my WordPress SEO guide covers the overlap between security and SEO in detail.

WordPress Migrations

I handle WordPress-to-WordPress migrations (from one host to another, or from a staging environment to production), and cPanel-based migrations where the hosting environment supports standard migration plugins (Duplicator, UpdraftPlus, or All-In-One WP Migration).

A migration I handle correctly includes: full content and database migration, redirect setup for any changed URLs (301 redirects to preserve SEO equity), Search Console and Analytics property verification on the new URL/host, and a post-migration crawl to catch any broken internal links or missing redirects.

What I Don’t Do in WordPress

I’m deliberately clear about scope because overpromising on capability is a common problem in freelance WordPress development:

• Custom PHP plugin development from scratch
• Custom theme development outside Elementor (i.e., writing a child theme from scratch)
• Complex REST API integrations with external platforms (beyond straightforward webhook setups)
• Multisite network administration
• Headless WordPress setups

If your project needs any of the above, I’ll tell you before we start rather than after you’ve invested in a contract.

Frequently Asked Questions

Do you build WordPress sites for specific industries?

I’ve built WordPress sites across a wide range of industries — law firms, medical practices, real estate agencies, e-commerce stores, SaaS landing pages, local service businesses, and professional service consultancies. The WordPress build process is largely the same across industries. What changes is the content strategy and the specific pages needed — which I adapt based on the client’s market and competitor landscape rather than using an industry-specific template.

Do you work with existing WordPress sites or only new builds?

Both. A significant portion of my WordPress projects involve improving or redesigning existing sites rather than building from scratch. This includes redesigning specific pages with Elementor while leaving the rest of the site untouched, migrating from one page builder to Elementor, fixing performance issues, or doing a complete redesign with content migration from the old site.

Can you work on a site that was built by another developer?

Yes, though the first thing I do is audit the existing build — plugin audit, performance review, and a check for the common issues that come from developers with different standards. If the existing site has major structural problems, I’ll document them and we’ll decide together whether to fix the existing build or start fresh. Starting fresh is not always the right answer, but sometimes it’s faster and cheaper than debugging another developer’s decisions.

How long does a typical WordPress build take?

A 5–8 page informational site in Elementor takes 1–2 weeks from brief to delivery, assuming content (text and images) is provided by the client. A 15–30 page site with WooCommerce integration takes 3–6 weeks. Timeline extension is almost always caused by delayed content delivery on the client side, not development — I factor this into project timelines upfront.