From notebook to business tool: a model anyone can run

Getting a model out of the notebook

A model in a Jupyter notebook only helps the person who can open the notebook. The person making the decision needs to type in real inputs and get an answer. Usually that means waiting on engineering. For internal tools, I don’t think you have to wait.

What I built

I trained a logistic regression on a loan dataset with four inputs, saved it, and wrapped it in a short Streamlit script. Fill in the form, click Check, and you get Approved or Rejected. It ran end to end and served the app locally.

1. Prepare

   Load the loan data and encode gender and marital status as numbers.

2. Train

   Fit a logistic regression on gender, marital status, applicant income and loan amount.

3. Save

   Write the trained model to a file the app can load.

4. Serve

   A Streamlit form takes the four inputs and returns Approved or Rejected.

Why this is how I work

This is the same path I take at work: get a minimum viable product in front of a test group, let the people who own the outcome try it, then decide what’s worth hardening. Streamlit fits when the audience is internal and the volume is modest. I get real feedback in days, and engineering only spends time on tools people have already proven they’ll use. The internal apps I build at work follow the same path.

What I’d change before anyone relied on it

• Validation. This was a demo. There’s no accuracy number and no held-out test set, so it isn’t a validated model.
• Protected characteristics. Gender and marital status are protected under fair-lending rules. I’d remove them and validate the model before it went near a real credit decision.
• Lifecycle. A real version needs monitoring and retraining triggers. It also needs access controls, logging and a fallback for when the model is down.
• Labels. A prototype stays labeled as a prototype until it passes the same validation and change control as any model that influences a decision.