Release context was scattered
Changes made during the week needed to be assembled into one reviewable view before production, instead of living across memory, tickets and individual change notes.
Retail SaaS · NDA · WordPress deployment automation
A custom WordPress plugin that makes weekly deploys visible, repeatable and testable.
For a retail SaaS platform deploying every Thursday, I built a custom WordPress automation plugin that turns the week's changed, edited and developed work into one pre-deploy manifest — then connects to the Kinsta-hosted environment over SSH after release to run automated smoke testing across the site.
WeeklyThursday deploy
1Pre-deploy manifest
SSHKinsta post-deploy automation
NDARetail SaaS client
The problem
Weekly deploys were predictable. The release knowledge around them wasn't.
The client is a retail SaaS company with a regular Thursday deployment cadence. During the week, fixes, content changes, technical edits and new development accumulate across the WordPress platform. By release day, the challenge is no longer just shipping code — it is knowing exactly what is going live and verifying that the production site still works afterwards.
The deploy needed a single source of truth
A Thursday release should start with a clear manifest of what changed, what was edited and what was developed — not a last-minute reconstruction.
Production QA needed to start automatically
Once Kinsta production was updated, the site still needed to be walked and checked for failures or missing expected elements without relying on somebody to remember every smoke-test step.
What the plugin automates
The plugin owns the release workflow on both sides of deployment.
This is operational WordPress plugin development: the feature is not a public-facing widget. It is internal release tooling designed around the way the SaaS team actually ships production changes.
All weekly changes in one pre-deploy view
The plugin surfaces the work changed, edited or developed during the week so the team can review one release manifest before Thursday's deployment.
Works with the existing deployment environment
The plugin does not replace the client's Kinsta workflow. It adds WordPress-specific release context before deployment and automation after production changes are live.
Post-deploy automation starts from the server side
After the release, the plugin connects to the Kinsta-hosted environment over SSH to start the smoke-testing stage of the workflow.
The site is walked automatically after deploy
The post-deploy process traverses the site and checks whether something fails or an expected element is missing, turning QA into a repeatable step rather than an ad-hoc checklist.
Failures are surfaced while the release is still fresh
The useful output is not “tests ran.” It is a clear signal that production needs attention when the smoke test finds something wrong or absent after deployment.
Thursday release workflow
From a week of changes to a verified production deploy.
The automation follows the client's existing operating rhythm instead of forcing a new release process onto the team.
Changes accumulate
Throughout the week, WordPress changes, edits and development work are added to the release context.
Pre-deploy review
Before Thursday's release, the plugin presents one manifest of what is expected to ship.
Deploy to Kinsta
The team releases through its existing Kinsta production workflow.
SSH smoke-test trigger
After deployment, the plugin connects over SSH and starts automated post-deploy testing.
Verify production
The site is traversed and the workflow flags failures or missing expected elements for review.
Architecture
WordPress becomes the release control layer.
The important engineering decision was to keep deployment context close to the application. A generic monitor can tell you that a URL is down. A ticket system can tell you what somebody planned to change. This plugin connects the two sides: what the WordPress team expects to ship and what production looks like immediately afterwards.
That makes the plugin an operational tool, not just another feature inside WordPress. It coordinates a release manifest, the client's existing Kinsta deployment process and automated site verification in one repeatable workflow.
- WordPress admin — weekly release context and pre-deploy manifest.
- Kinsta production — the client's existing hosting and deployment environment.
- SSH automation — post-deploy connection used to start smoke testing.
- Site-wide verification — automated traversal looking for failures or missing expected elements.
- Release feedback — issues surface as part of the same deployment workflow.
Why custom plugin development
This workflow was too specific to solve cleanly with a generic plugin.
The value comes from knowing the client's weekly release context, working with its Kinsta environment and triggering WordPress-specific verification after deployment. A generic monitoring tool sees production. A project board sees planned work. The custom plugin joins those two operational views.
It knows what the team expects to ship
The pre-deploy manifest is built around the client's actual WordPress workflow instead of a generic release checklist.
It works with Kinsta instead of replacing it
The hosting/deployment platform stays in place. The plugin adds orchestration around the application and release process.
It closes the loop after production changes
The same workflow that explains what is going live also starts the smoke test that checks the site after deployment.
Outcome
Deployment knowledge became a repeatable system instead of tribal memory.
No fabricated percentage belongs here: this is a process automation case study, not a vanity-metric story. The operational improvement is that every Thursday release has a visible pre-deploy context and an automated post-deploy verification step tied to the same workflow.
The client name and internal implementation details are withheld under NDA. The workflow described here reflects production work for a retail SaaS platform.
- One reviewable view of the week's WordPress changes before deployment.
- Post-deploy smoke testing starts as part of the release workflow.
- Failures or missing expected elements surface earlier after production changes.
- The Thursday deployment process is less dependent on memory and manual checklists.
- Custom release tooling stays close to the WordPress application it is verifying.
What this demonstrates
Custom WordPress plugins can automate operations, not just add frontend features.
This case combines custom WordPress plugin development, deployment automation, Kinsta integration, SSH orchestration and post-deploy smoke testing. It is the kind of internal engineering work that generic plugins usually cannot model because the workflow belongs to one business.
FAQ
WordPress deployment automation questions.
Yes. A purpose-built plugin can collect release context before deployment and orchestrate post-deploy verification around the way a team actually ships WordPress. In this case, the plugin combines a weekly change manifest with automated smoke testing after the Kinsta deployment.
The client workflow needed an automated step after production deployment. The plugin connects to the Kinsta-hosted environment over SSH so the smoke-test process can start as part of the same release workflow instead of relying on a manual checklist.
No. It complements the existing Kinsta deployment workflow. Kinsta remains the hosting and deployment environment; the custom plugin adds application-level release context before deployment and automated WordPress-specific verification afterwards.
The smoke-test step walks the site after deployment and flags failures or missing expected elements so the team can see whether production still behaves as expected. The exact checks are tailored to the site and release workflow.
Yes. The pattern is portable: capture release context, deploy through the existing hosting workflow, then trigger automated verification. The implementation changes depending on the host, deployment pipeline and secure access available.
Need a WordPress plugin for a workflow your stack does not understand?
Send me the release process, the current WordPress setup and the systems around it. I will tell you whether custom plugin development is the cleanest way to automate it.
