A FastAPI service with monitoring and a retraining script your engineers can run themselves. One fixed price quoted before any code gets written. Code in your repo on week five.
PROBLEMS I HEAR EVERY WEEK
By the time the email lands, the decision was made weeks ago. A churn model flags at-risk accounts 30 to 90 days early, when a CSM call can still change the outcome. Built on your account-level usage history, billing events, and support tickets.
Intuition-based ordering is expensive in two directions: spoilage on the high side, stockouts on the low side. A demand forecasting model trained on your historical sales and seasonal patterns cuts both at once. I built this for perishable inventory at LIFO AI across multiple retail locations.
A lead scoring model ranks your inbound pipeline by conversion probability based on your CRM history. Your best reps focus on the deals most likely to close, not the ones that replied fastest. The scoring lives in your CRM as a field your team can sort by.
A notebook is a demo. Production needs a serving layer, monitoring, and a retraining script your team can run without me. Every system I ship is built for production from week one, with a runbook your engineers can keep alive after I'm gone.
Black-box models kill adoption. SHAP explanations come with every model I ship: per-prediction feature attribution your team can read on the same dashboard they already use. They know why each call was made and can push back when something doesn't look right.
Real-time anomaly detection on transaction or sensor streams flags unusual patterns as they happen. The difference between an early flag and a cleanup project that runs for a quarter. The public fraud project on my GitHub catches 84% of fraud at 0.28% alert volume on a 577:1 imbalanced dataset.
How I solve it
Each move maps back to one of the quotes above. None of them is optional.
The "we built it and never used it" failure starts with a fuzzy target. Week 1 produces a one-page scoping doc that names the business decision, the cost-of-error numbers, and the success threshold. Both of us sign off before training begins. The notebook never sits unused if both sides agreed up front on what decision the output was going to inform.
Churn predictions don't come from a vibe. They come from feature engineering on your usage logs, billing events, and support tickets. Lead scoring runs on your CRM history. Demand forecasts run on your POS data. I built that stack at LIFO AI on Square POS data and would build it the same way on your stack.
The "80/20 of revenue" lead problem and the "fraud caught too late" problem are both threshold problems. F1 score doesn't know that a missed fraud costs $10K and a false positive costs the ops team an hour. I run threshold tuning against your real numbers and ship the tuning script so you can re-run it as the numbers shift.
Black-box models kill adoption. Every model I ship surfaces per-prediction feature attribution on the same dashboard your team already uses. Your CSM or fraud analyst reads the explanation in plain feature names before acting on the score.
A notebook is a demo. A service your engineers can run without me is a product. I wrap the model in FastAPI, push to your repo, and ship a monitoring dashboard and a retraining script your team runs on a schedule. After week five, your team owns the system.
The operational lifecycle, after handoff. Training data pipeline feeds a feature store. Model trained, evaluated, and explained with SHAP. Deployed as a FastAPI endpoint or batch job. Performance and drift monitored continuously. Retrained on a schedule your team owns.
The Setup: The Credit Card Fraud Detection dataset on Kaggle. 284,807 transactions, 0.17% fraud rate, 577:1 class imbalance. Most fraud-detection tutorials skim past how brutal that imbalance is once it hits production. This project takes it seriously.
What got built: A LightGBM classifier with feature engineering across log-transformed amounts, hour-of-day patterns, z-score normalization, and rolling velocity statistics. Threshold tuning with explicit cost-of-error reasoning. A Streamlit dashboard with per-transaction SHAP explanations and three action recommendations: auto-block, manual review, or allow.
Stack: Python, LightGBM, scikit-learn, pandas, Streamlit.
See the GitHub repoThe Setup: A food-tech startup needed forecasts for perishable inventory across multiple retail locations. Stale predictions cost the business spoilage. Slow predictions cost it stockouts. Both come out of the same inventory the platform can't refund.
What got built: A FastAPI ML service that runs demand forecasting and shelf-life prediction. Square POS data flows in. Reorder logic runs on top of the predictions. PostgreSQL stores features and predictions. Retraining is scheduled and runs without taking the API down. Predictions refresh nightly.
Stack: Python, FastAPI, PostgreSQL, scikit-learn, Square POS integration
Work done as AI Engineer at LIFO AI between November 2025 and March 2026.
Get a similar resultDELIVERABLES
A one-page scoping doc that names the business decision, the cost-of-error numbers, and a measurable success threshold
A data audit covering schema checks, completeness, leakage detection, and train-test split design
A baseline model and benchmark, often shipped as the final answer if it clears the bar
A production model with threshold tuning matched to your actual business costs
A FastAPI service, containerized with Docker, deployable to your existing infrastructure
SHAP explanations on every prediction, surfaced on the same dashboard your team already uses
A monitoring dashboard for drift and performance, built on your existing stack
A retraining script your team runs on a schedule, with a README a backend engineer can follow
A 30-day post-deployment review against business metrics
How It Works
A 20-minute call. We go through your data and the decision the model is meant to inform. I tell you straight whether ML is the right answer for your case. No deck. No pitch.
I write up a one-page scoping doc that covers the business decision, the cost-of-error numbers, the success threshold, the stack, and your fixed price. If at the end of the week it isn't the right fit, you keep the document and we part ways. No contract trap.
Data audit. Train-test split. Simplest model that could possibly work, run end-to-end with metrics on a held-out set. Sometimes the baseline is good enough and we ship from here. Otherwise we move to feature engineering and threshold tuning calibrated to your actual business costs.
Wrap the model in a FastAPI service. Deploy to staging. Build the monitoring dashboard and the retraining script. Push everything to your repo, not mine.
Code review with your engineers. Walkthrough of the retraining loop, the runbook, and the monitoring dashboard. After this week, your team owns the system.
What slows the build down. Data leakage hidden in your training set. A poorly defined target variable. Infrastructure that has to be built before the model can ship. I flag these in week 1 if I see them coming.
If you're not sure which side you fall on, book the call. I'll tell you straight.
Two things decide it. First, the decision needs to be made enough times per day that automation matters. Second, you need at least 6 months of clean historical data on the target you want to predict. If either answer is no, a SQL query or a threshold rule is the better starting point. I'll tell you on the scoping call which side your problem falls on.
Computer vision and large-scale NLP. If your problem needs either, I'll tell you on the scoping call and point you at someone better. Forecasting, scoring, and anomaly detection on tabular data is the lane I work in.
Most production datasets are imbalanced. The fraud project on my GitHub handles a 577:1 imbalance using LightGBM with threshold tuning and rolling features. For very small datasets (fewer than 1,000 rows of the rare class), I push back and recommend collecting more data or starting with rules-based logic before any model.
Rarely. I have not shipped deep learning to production yet. For most early-stage SaaS prediction problems, gradient boosting (LightGBM, XGBoost) is the better starting point and is what I'd default to. If your problem actually needs deep learning, the scoping call will say so and I'll point you at a specialist.
For tabular models like LightGBM, the FastAPI service runs on whatever VPS your API already uses. Retraining on CPU is mostly your team's time. Deep learning models cost more on the cloud at each retrain. The scoping call covers this for your specific case.
By the business decision, not the F1 score. The fraud project's headline metric is "84% of fraud captured at 0.28% alert volume" because that's what an ops team cares about. Every scoping doc starts with the business metric and works back to the technical one.
Both. The model is roughly 30% of the work. The data pipeline, the FastAPI service, the monitoring, the retraining script, and the runbook are the other 70%. A model that isn't deployed is shelfware.
SHAP on every prediction. Global feature importance for the model overall, plus per-prediction explanations on the dashboard your team uses. If a sales rep gets a "this lead won't close" score, they can see the three or four features that drove it.
Me. There's no junior to hand the work to. I take a maximum of two engagements at a time so each one gets full attention.
Lead time is one to two weeks. ML engagements run 4 to 8 weeks depending on data quality and how much infrastructure has to be built before the model can ship.
A 20-minute scoping call. We go through your data, the decision you want the model to inform, and whether ML is even the right answer for your case. A one-page proposal lands in your inbox within 48 hours of the call.