I have lost count of the clients who have asked me to “add AI” to their WooCommerce store. Usually they saw a Jupyter Notebook demo somewhere and it looked like magic. The awkward part is the distance between a model that runs on a data scientist’s laptop and ML in production that stays stable under real traffic.
It is worth being precise about what production means here. Plenty of developers use the word as a synonym for “deployed.” After enough 3 AM pages for race conditions and memory leaks, I use it to mean something narrower: accountability. If your model fails and nothing in the system notices, you are not in production. You are hosting a problem that has not surfaced yet.
Why 87% of models fail
The statistic gets quoted a lot: most machine learning projects never reach the finish line. The math is rarely the reason. What is missing is the engineering around the math. A model gets treated as a standalone decision engine when it is really one component inside a layered architecture.
Once you move ML in production, the model is one stage in an ETL (Extract, Transform, Load) pipeline. Messy storage or brittle acquisition logic will feed garbage to the best model you can train, and it will hand garbage back. The five steps below are the parts I end up building on every one of these projects.
Steps 1 and 2: from local function to API contract
Step one is the function. It loads the model and returns a prediction. In a WordPress environment, though, you should not be loading heavy Python models inside PHP at all. I have seen sites call shell_exec to run a Python script on every page load. Please do not do that. It is a bottleneck that will take the server down long before it makes anyone money.
Step two is the interface, usually a FastAPI or Flask wrapper. Treat it as a contract. If WordPress expects /v1/predict to return a JSON object, that shape cannot change without warning. The interface also owns validation. A missing value should not crash the service, it should come back as a clean 422.
<?php
/**
* Example of how to properly interface with an ML API in WordPress.
* Do NOT load models in PHP. Call a dedicated service.
*/
function bbioon_get_model_prediction( $user_data ) {
$api_url = 'https://api.your-ml-service.com/v1/predict';
$response = wp_remote_post( $api_url, [
'body' => wp_json_encode( $user_data ),
'headers' => [ 'Content-Type' => 'application/json' ],
'timeout' => 5, // Always set a timeout for ML in production
]);
if ( is_wp_error( $response ) ) {
// Log the error and return a safe fallback
error_log( 'ML API Failure: ' . $response->get_error_message() );
return bbioon_get_fallback_recommendation();
}
return json_decode( wp_remote_retrieve_body( $response ), true );
}Steps 3 and 4: environment and infrastructure
Step three is portability, which is where “it works on my machine” usually falls apart. Docker earns its keep here for ML in production: code, dependencies and model weights all go into one container. Deploy that to AWS or to an edge device and the behavior stays the same.
Step four is infrastructure, and ML workloads tend to want GPUs or high-memory instances. For most WordPress sites I point people at AWS Bedrock or a managed service instead of running their own GPU cluster. Maintaining a cluster is a second job, and most teams do not need one.
Step 5: monitoring for silent decay
A broken PHP hook throws a 500 and someone notices within the hour. Models are quieter than that. Inputs shift over three months, nothing errors, and one day your “High Quality” predictions are worthless. That is drift, and it is why you watch input distributions alongside latency. A service that is up while its predictions are statistically skewed is still broken, just harder to page someone about.
If this side of ML in production is eating your dev hours, I can take it off your plate. I have been working on WordPress and backend architecture since the 4.x days.
Ship the system around the model
ML in production is mostly a change in the question you are answering. “Can I make this prediction?” becomes “can I keep making this prediction at scale, without babysitting it?” ONNX helps with portability and an API keeps concerns separate, but the thing that saves you is a rollback plan you have actually tested. Most of that 87% did not fail on the math. Nobody built the system around the model.
