ai Case study
WooCommerce Diagnostic Assistant
Most WordPress audit tools produce the same report for every site. This one starts from the actual install: it connects over the REST API, reads what is really configured, and reasons about that rather than about what a typical WooCommerce site looks like.
The business problem
Diagnosing a WooCommerce site is mostly pattern recognition over a lot of small signals, and the standard tooling is either a fixed checklist that ignores context or a plugin that has to be installed on the site being diagnosed. I wanted something that could look at a store from the outside, using credentials the owner controls, and produce findings specific enough to act on.
What I delivered
- A FastAPI service exposing both a diagnostic API and a browser interface, so it can be used interactively or called from another tool.
- A WordPress connector that authenticates with an application password over the REST API, which means no plugin has to be installed on the target site and access can be revoked from the WordPress user screen.
- A configuration layer holding the WordPress endpoint, credentials and model selection separately from the diagnostic logic.
- A dedicated connector error type, so a site that is unreachable, misconfigured or returning an unexpected shape produces a clear message rather than a stack trace.
- Model selection as configuration rather than a hardcoded choice, so the engine can be changed without touching the diagnostic code.
Technical approach
- Application passwords rather than a plugin or an API key of my own. The site owner grants access, sees it listed among their users, and revokes it themselves.
- The connector is isolated behind its own module and error type, because most real failures here are transport and permission problems rather than reasoning problems, and they should read differently.
- Configuration is separated from logic so credentials never end up embedded in the analysis path.
- The interface and the API share the same core, so anything the browser view can report is also available programmatically.
Result and evidence
A store can be assessed from the outside, without installing anything on it, and the findings reference what that install actually has rather than a generic best-practice list. The service runs as a standalone tool against real sites.
Commercial value
For anyone maintaining several WooCommerce stores, the useful property is that assessment does not require touching the site. Read-only credentials, revocable by the owner, and no additional plugin surface on a production store.
Readable implementation brief
implementation_brief {
project: "WooCommerce Diagnostic Assistant"
stack: "Python, FastAPI, Jinja2 templates, Pydantic config"
access: "WP REST API + application password, owner-revocable"
install_on_target: "nothing"
structure: "core/wp_connector + core/config, isolated from
the diagnostic path"
errors: "dedicated connector error type, so transport and
permission failures never read as findings"
model: "selectable via config, not hardcoded"
}What this project shows
The design decision I would defend is authenticating with an application password the owner controls, rather than asking them to install my code. It changes the trust conversation entirely.
Giving the connector its own error type is a small thing that matters in practice: it keeps infrastructure failures from being reported as analysis results.