From notebook to business tool: a model anyone can run

A model nobody can use isn’t worth much

A model sitting in a notebook is a science project. It only matters when the person making the decision can type in real inputs and get an answer. Usually that means waiting on engineering. For internal tools, I don’t think it has to.

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. It turns weeks of waiting into days of real feedback, and engineering time goes to what has already proven itself. It’s how I approach the internal apps I build.

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. Shipping is the start. A real version needs monitoring, retraining triggers, access controls, logging and a fallback 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.