Numan Zahid · Web Developer · Remote
I've been doing this since 2016. Lots of WordPress, these days mostly Next.js and Astro, and quite often the API, plugin or import script that the site depends on. That last part is usually where the interesting problems are.
I've left client names out. Most of this work is under confidentiality agreements.
Vacancies moved from an embedded listing to individually indexable routes, with WordPress kept as the editor and a custom plugin as the adapter.
A new site on Next.js or Astro. I'll plan the CMS and any integrations at the start too, because adding them at the end is where most projects get messy.
Example: a job boardGetting off an old theme or page builder without breaking your URLs. I script the redirects from your existing links, so nothing gets missed.
Example: WordPress to AstroHooking your site up to the system your data already lives in, or building an API for it. That includes planning for the days that system is slow or down.
Example: a jobs APIWhen WordPress can't do what you need out of the box. A proper plugin is easier to look after than a hack in the theme that the next update breaks.
Example: a Substack syncTakes exam results from spreadsheets through validation, review and approval, then publishes the approved set to a public site, centre reports and print.
Podcasts, videos and articles unified behind one GraphQL layer, with the content model and editorial fields version-controlled as plugin code.
Pulls vacancies out of several recruitment systems, normalises them, and republishes them behind one contract, so a site integrates once, not once per platform.
Brings an external publication into WordPress as native posts while the team keeps writing their own, with a configurable line between what each side owns.
A content-heavy site moved off WordPress onto prerendered Astro, with every legacy URL mapped by a script rather than by hand.
A film-inspired studio site with a custom carousel and gallery lightbox, built so the animation is islands and everything around it is static HTML.
A marketing page can be a plain file on a CDN. A job listing that changes every hour needs refreshing when it changes. A dashboard behind a login shouldn't be prebuilt at all. I pick per page, not per site.
It's the editor most teams are happy to use, so I keep it. But visitors don't need to hit it on every request. I pull the content at build time or through an API, and the public site stays fast.
Hand-written structured data drifts out of date within a couple of releases, and wrong markup is worse than none. I generate it from the same data the page renders, so the two always match.
Any cache makes a demo look fast. What matters is what happens when the content changes. If the only answer is 'clear everything', it'll cause an outage sooner or later.
If an automated import and a person can both edit the same field, someone's changes will vanish without anyone noticing. So I decide upfront which fields the sync owns and lock them at the database level, not just in the UI.
The people using your API want to ask what's changed since yesterday, get a quick 'nothing' when nothing has, and have one key revoked without everyone else's breaking. Adding any of that later breaks things for them, so I build it in from the start.
I started building websites in 2016, mostly custom WordPress themes. I did a lot of those, and I've since had to maintain plenty of other people's. That's taught me to care a lot about what a site is like to work on a year after launch.
A lot of the projects I get have the same problem. The site's design and its data are so tangled together that you can't change one without breaking the other. Important content often doesn't have its own page either, so it can't show up in search.
My fix is usually to separate them. The data lives in one place, editors keep the CMS they already know, and the public site becomes fast static pages. Sometimes that means writing the API or plugin that connects it all, which I enjoy more than I probably should.
Usually, yes. On most of these projects WordPress stayed exactly where it was. Your team keeps the same admin, accounts and content. I just change how the public pages get built.
No. You keep publishing the way you do now, often with the same plugins you already use. If people need retraining after I hand over, I haven't done my job.
It shouldn't. I generate the redirects from your old URLs with a script and carry your SEO titles and descriptions across, so old links keep working from launch day.
No. They're what I use for most front ends, but I do a fair bit of Laravel and Django too, and I spent years on regular WordPress themes before any of that. What you end up with should depend on who's going to maintain it.
Then I'll probably write a plugin for it. Three of the projects here include one, for things like a custom API for the front end or pulling in posts from Substack.
Email me with where things are now and what you'd like to change. If I'm not the right person for it, I'll tell you, and I'll usually know someone who is.
hello@zahid.dev