DEV Community: Mwenda Harun Mbaabu

Deploying Machine Learning Models with FastAPI

Mwenda Harun Mbaabu — Tue, 18 Aug 2026 11:32:18 +0000

A practical journey from training a machine learning model in a notebook to exposing it as an API and connecting it to a real user interface.

Building a machine learning model is an important achievement. But training a model is not the end of the machine learning lifecycle.

For many people learning Data Science and Machine Learning, the journey often looks like this:

Collect a dataset
Clean the data
Perform exploratory data analysis
Engineer features
Train several models
Evaluate their performance
Select the best model
Generate predictions
Save the notebook

At that point, the model works. But only inside your environment. A real-world machine learning system needs to go further.

The model needs to become accessible to:

Web applications
Mobile applications
Internal business systems
Other developers
Data platforms
Customer-facing applications

This is where Machine Learning Model Deployment becomes important.

In our upcoming FastAPI Fundamentals and Deploying Machine Learning Models with FastAPI Workshop, we will explore how to take a trained machine learning model and expose it through a production-style REST API using Python and FastAPI.

The goal is not simply to train better models, the goal is to build machine learning systems that people and applications can actually use. Move machine learning beyond the notebook and make it usable in real applications.

What We Will Build.

By the end of the workshop, we will deploy a Customer Churn Prediction Model and connect it to a ready-made web interface.

The user interface will already be developed and made available to all participants.

This allows us to concentrate on the most important part of the workshop: building the machine learning backend and exposing the model through API endpoints.

Our workflow will therefore focus on:

Understanding APIs
Understanding FastAPI
Building API endpoints
Loading a trained machine learning model
Validating incoming customer data
Sending the data to the model
Generating churn probabilities
Returning predictions as JSON
Connecting the FastAPI API to the frontend UI

When everything is connected, a user will be able to enter customer information into the interface and receive a result such as:

prediction_response = {
    "prediction": "Likely to Churn",
    "churn_probability": 0.81
}

Instead of seeing:

prediction = 1

The end user could see something meaningful:

result = {
    "prediction": "Likely to Churn",
    "risk_level": "High",
    "churn_probability": "81%",
    "recommendation": "Consider retention outreach or a discount offer."
}

That is the transition from a machine learning experiment to a machine learning application.

The Problem: Your Model Works, But Only on Your Computer.

Imagine that you have spent several hours building a machine learning model.

You have successfully:

Collected your dataset
Cleaned and transformed the data
Performed exploratory data analysis
Selected important features
Split the data into training and testing sets
Trained several machine learning algorithms
Evaluated their performance
Selected the best-performing model

Eventually, you run:

prediction = model.predict(new_data)

print(prediction)

And the model returns:

prediction = [1]

Great.

Your machine learning model works. But there is still a problem.

Who can actually use it?

At this point, probably only someone who has:

Your Jupyter Notebook
Python installed
Your dependencies installed
Access to the trained model
Knowledge of your preprocessing steps
Knowledge of your Python code

That is not practical for a real application. Consider a telecom company using your churn model.

A customer service officer should not need to open Jupyter Notebook and run:

model.predict(customer_data)

A web application should not need to understand how Random Forest works. A mobile application should not need access to your notebook. A CRM should not need your entire machine learning project.

Instead, these applications should simply send data to your model and receive a prediction.

This is where APIs become extremely useful.

What Is an API?

API stands for:

Application Programming Interface

An API provides a structured way for software applications to communicate with each other.

Think of an API as an intermediary. One application sends a request. Another application processes that request. A response is returned.

For our machine learning system, the communication might look like this:

Frontend

↓

API

↓

Machine Learning Model

↓

Prediction

↓

API

↓

Frontend

Suppose our Customer Churn Prediction system exposes this endpoint:

endpoint = "/predict"

The frontend sends customer information to the endpoint.

For example:

customer_data = {
    "tenure": 12,
    "monthly_charges": 89.50,
    "contract": "Month-to-month",
    "internet_service": "Fiber optic",
    "payment_method": "Electronic check",
    "paperless_billing": "Yes",
    "senior_citizen": "No",
    "dependents": "No"
}

The API receives the information. It then passes the customer data to the machine learning model.

The model calculates a prediction. The API returns:

response = {
    "prediction": "Likely to Churn",
    "churn_probability": 0.81
}

The frontend can now display:

The application using our API does not need to understand how our model was trained.

It does not need to know whether we used:

Logistic Regression
Random Forest
XGBoost
Gradient Boosting
Neural Networks

It only needs to understand the API contract:

api_contract = {
    "endpoint": "/predict",
    "method": "POST",
    "input": "Customer information",
    "output": "Churn prediction"
}

This separation is extremely powerful.

Why FastAPI?

For this workshop, we will use FastAPI. FastAPI is a modern Python framework designed for building APIs.

It is particularly attractive for machine learning applications because most machine learning development already happens inside the Python ecosystem.

A Data Scientist or Machine Learning Engineer may already be working with:

Pandas
NumPy
Scikit-learn
XGBoost
PyTorch
TensorFlow
Joblib

Adding FastAPI means we can build the serving layer without abandoning Python.

A very simple FastAPI application can look like this:

from fastapi import FastAPI

app = FastAPI()


@app.get("/")
def home():
    return {
        "message": "Machine Learning API is running."
    }

We can make our application slightly more descriptive:

from fastapi import FastAPI


app = FastAPI(
    title="Customer Churn Prediction API",
    description="Machine Learning API for predicting customer churn.",
    version="1.0.0"
)


@app.get("/")
def home():
    return {
        "status": "healthy",
        "message": "Customer Churn Prediction API is running."
    }

Already, we have created a working API.

The Journey From Notebook to Production.

Our workshop will follow this architecture:

Raw Data

↓

Data Cleaning

↓

Feature Engineering

↓

Model Training

↓

Model Evaluation

↓

Model Pipeline

↓

Save Model

↓

FastAPI Application

↓

Prediction Endpoint

↓

Frontend

↓

User

In Python, we could represent the lifecycle as:

machine_learning_lifecycle = [
    "Data Collection",
    "Data Cleaning",
    "Exploratory Data Analysis",
    "Feature Engineering",
    "Model Training",
    "Model Evaluation",
    "Model Persistence",
    "API Development",
    "Model Serving",
    "Frontend Integration"
]

The important idea is that machine learning does not exist in isolation.

Eventually, it must interact with other software systems.

Our Business Problem: Customer Churn.

For the workshop, our main project will be Customer Churn Prediction. Customer churn occurs when a customer stops using a company's service.

Examples include customers:

Cancelling a telecommunications subscription
Closing a bank account
Cancelling an insurance policy
Leaving a streaming platform
Cancelling a SaaS subscription
Moving to another internet provider

For many companies, customer retention is extremely important.

Our machine learning problem can therefore be stated as:

Given information about a customer and their subscription behaviour, can we estimate their likelihood of leaving the company?

Our model might consider features such as:

Customer tenure
Monthly charges
Contract type
Internet service
Payment method
Paperless billing
Senior citizen status
Dependents
Services subscribed to

Our target might be:

target = "churn"

Where:

churn_labels = {
    0: "Not Likely to Churn",
    1: "Likely to Churn"
}

This makes Customer Churn a binary classification problem.

Step 1: Prepare the Data.

Before training the model, we separate our features and target.

For example:

target_column = "Churn"

X = df.drop(columns=[target_column])
y = df[target_column]

We then divide the dataset into training and testing sets.

from sklearn.model_selection import train_test_split


X_train, X_test, y_train, y_test = train_test_split(
    X,
    y,
    test_size=0.20,
    random_state=42,
    stratify=y
)

Why do we split the data?

Because we want to evaluate the model using observations it did not see during training.

Step 2: Build a Preprocessing Pipeline.

Real-world datasets rarely contain only perfectly formatted numerical values.

Our churn dataset may contain:

Numerical features

numerical_features = [
    "tenure",
    "monthly_charges"
]

and categorical features:

categorical_features = [
    "contract",
    "internet_service",
    "payment_method",
    "paperless_billing",
    "senior_citizen",
    "dependents"
]

We therefore need preprocessing.

Instead of manually repeating preprocessing every time we generate a prediction, we can build a reusable Scikit-learn pipeline.

from sklearn.compose import ColumnTransformer
from sklearn.preprocessing import OneHotEncoder, StandardScaler
from sklearn.pipeline import Pipeline


numerical_transformer = Pipeline(
    steps=[
        (
            "scaler",
            StandardScaler()
        )
    ]
)


categorical_transformer = Pipeline(
    steps=[
        (
            "encoder",
            OneHotEncoder(
                handle_unknown="ignore"
            )
        )
    ]
)


preprocessor = ColumnTransformer(
    transformers=[
        (
            "numerical",
            numerical_transformer,
            numerical_features
        ),
        (
            "categorical",
            categorical_transformer,
            categorical_features
        )
    ]
)

This is an important production concept.

The same preprocessing transformations used during training should also be used when new requests arrive through our API.

Step 3: Train the Machine Learning Model.

We can combine our preprocessing and classification algorithm into one pipeline.

For example:

from sklearn.ensemble import RandomForestClassifier
from sklearn.pipeline import Pipeline


classifier = RandomForestClassifier(
    n_estimators=200,
    random_state=42,
    class_weight="balanced"
)


model_pipeline = Pipeline(
    steps=[
        (
            "preprocessor",
            preprocessor
        ),
        (
            "classifier",
            classifier
        )
    ]
)

Now we train the complete pipeline.

model_pipeline.fit(
    X_train,
    y_train
)

Notice what we are doing here.

We are not saving only the classifier.

We are creating:

Raw Customer Data

↓

Preprocessing

↓

Feature Transformation

↓

Random Forest

↓

Prediction

as one reusable pipeline.

Step 4: Evaluate the Model.

Training a model is not enough.

We need to understand how well it performs.

from sklearn.metrics import (
    accuracy_score,
    precision_score,
    recall_score,
    f1_score
)


y_pred = model_pipeline.predict(
    X_test
)


evaluation = {
    "accuracy": accuracy_score(
        y_test,
        y_pred
    ),
    "precision": precision_score(
        y_test,
        y_pred
    ),
    "recall": recall_score(
        y_test,
        y_pred
    ),
    "f1_score": f1_score(
        y_test,
        y_pred
    )
}


print(evaluation)

For churn prediction, we should not look at accuracy alone.

Imagine we care about identifying customers who are genuinely at risk of leaving.

In that situation, recall becomes particularly important.

It helps us answer:

Of all the customers who actually churned, how many did our model identify?

Machine learning metrics should therefore always be interpreted in the context of the business problem.

Step 5: Save the Complete Model Pipeline.

Once we are satisfied with our model, we save it.

We can use Joblib.

import joblib


MODEL_PATH = "model/customer_churn_pipeline.joblib"


joblib.dump(
    model_pipeline,
    MODEL_PATH
)

Now we have a reusable machine learning artifact.

The important distinction is:

Jupyter Notebook

Used for:

Exploration
Experimentation
Model development
Training
Evaluation

Saved Model

Used for:

Prediction
Serving
Applications
Production systems

Our API does not need to retrain the model for every request.

It simply loads the trained model.

Step 6: Organise the Project.

A professional project should have a clear structure.

For example:

project_structure = """
customer-churn-fastapi/
│
├── app/
│   ├── __init__.py
│   ├── main.py
│   ├── schemas.py
│   ├── model_loader.py
│   └── predictor.py
│
├── data/
│   └── customer_churn.csv
│
├── model/
│   └── customer_churn_pipeline.joblib
│
├── notebooks/
│   └── model_training.ipynb
│
├── tests/
│   └── test_api.py
│
├── requirements.txt
├── README.md
└── .gitignore
"""

Each component has a responsibility.

The notebook trains the model.

The model directory stores the trained artifact.

The application directory contains the API.

The tests directory contains API tests.

This separation makes the project easier to understand and maintain.

Step 7: Load the Model Into FastAPI

We can create a small model loader.

from pathlib import Path

import joblib


MODEL_PATH = (
    Path(__file__).resolve().parent.parent
    / "model"
    / "customer_churn_pipeline.joblib"
)


def load_model():
    model = joblib.load(
        MODEL_PATH
    )

    return model

Our API can now reuse the model without retraining it.

Step 8: Define the API Input Schema

When the frontend sends information, our API should know exactly what fields to expect.

We can define this using Pydantic.

from pydantic import BaseModel, Field


class CustomerInput(BaseModel):

    tenure: int = Field(
        ...,
        ge=0,
        description="Number of months the customer has stayed."
    )

    monthly_charges: float = Field(
        ...,
        ge=0,
        description="Customer monthly charges."
    )

    contract: str

    internet_service: str

    payment_method: str

    paperless_billing: str

    senior_citizen: str

    dependents: str

This gives our API an explicit data contract.

If someone sends:

invalid_request = {
    "tenure": "twelve months",
    "monthly_charges": "expensive"
}

FastAPI can reject the request before invalid data reaches the machine learning model.

Input validation is therefore not simply convenient.

It is part of building reliable systems.

Step 9: Create the Prediction Endpoint

Now we arrive at the central part of the workshop.

We connect FastAPI to our trained model.

import pandas as pd

from fastapi import FastAPI

from app.model_loader import load_model
from app.schemas import CustomerInput


app = FastAPI(
    title="Customer Churn Prediction API",
    description=(
        "REST API for serving predictions "
        "from a trained customer churn model."
    ),
    version="1.0.0"
)


model = load_model()


@app.get("/")
def home():

    return {
        "status": "healthy",
        "service": "Customer Churn Prediction API"
    }


@app.post("/predict")
def predict_churn(
    customer: CustomerInput
):

    input_data = pd.DataFrame(
        [
            customer.model_dump()
        ]
    )

    prediction = model.predict(
        input_data
    )[0]

    probabilities = model.predict_proba(
        input_data
    )[0]

    churn_probability = probabilities[1]

    prediction_label = (
        "Likely to Churn"
        if prediction == 1
        else "Not Likely to Churn"
    )

    return {
        "prediction": prediction_label,
        "churn_probability": round(
            float(churn_probability),
            4
        )
    }

Now our machine learning model is accessible through:

prediction_endpoint = "POST /predict"

This is a major transition.

Before:

Notebook → model.predict()

Now:

Application → API → Model → Prediction → Application

Our model has become a service.

Step 10: Run the FastAPI Application

We can start the API using Uvicorn.

command = "uvicorn app.main:app --reload"

The development server will typically become available at:

api_url = "http://127.0.0.1:8000"

FastAPI also automatically generates interactive API documentation.

swagger_docs = "http://127.0.0.1:8000/docs"

This means that before connecting our UI, we can test the machine learning API directly from our browser.

Step 11: Send a Prediction Request.

Our frontend might eventually send information similar to:

customer = {
    "tenure": 12,
    "monthly_charges": 89.50,
    "contract": "Month-to-month",
    "internet_service": "Fiber optic",
    "payment_method": "Electronic check",
    "paperless_billing": "Yes",
    "senior_citizen": "No",
    "dependents": "No"
}

The request is sent to:

endpoint = "POST /predict"

Our FastAPI backend sends the customer information through:

prediction = model.predict(
    input_data
)

and:

probability = model.predict_proba(
    input_data
)

The API returns:

response = {
    "prediction": "Likely to Churn",
    "churn_probability": 0.81
}

The frontend then converts this machine-readable response into something useful for a human.

For example:

interface_result = {
    "status": "Likely to Churn",
    "churn_probability": "81%",
    "risk": "High",
    "recommendation": (
        "Consider retention outreach "
        "or a discount offer."
    )
}

From Model Output to Business Decision.

This is an important distinction. A machine learning model might technically return:

raw_prediction = 1

But 1 means very little to a business user.

We therefore transform the prediction into something understandable:

business_prediction = {
    "customer_status": "Likely to Churn",
    "probability": "81%",
    "risk_level": "High"
}

We can go further and connect it to a business action:

business_action = {
    "risk_level": "High",
    "recommended_action": (
        "Prioritise customer for retention outreach."
    )
}

This is ultimately why machine learning systems are built.

Not simply to produce numbers.

But to support decisions.

Connecting FastAPI to the User Interface

The final architecture will look like this:

USER

↓

CUSTOMER CHURN UI

↓

POST /predict

↓

FASTAPI

↓

PYDANTIC VALIDATION

↓

PREPROCESSING PIPELINE

↓

MACHINE LEARNING MODEL

↓

CHURN PROBABILITY

↓

JSON RESPONSE

↓

CUSTOMER CHURN UI

↓

USER

The frontend and machine learning model are therefore separated.

The frontend is responsible for presentation.

FastAPI is responsible for communication and serving.

The machine learning pipeline is responsible for prediction.

Separation of Responsibilities

A clean architecture might look conceptually like this:

system_components = {

    "frontend": {
        "responsibility": (
            "Collect user input and display results"
        )
    },

    "fastapi": {
        "responsibility": (
            "Receive requests, validate input "
            "and return responses"
        )
    },

    "machine_learning_pipeline": {
        "responsibility": (
            "Transform data and generate predictions"
        )
    }
}

This separation is one of the principles behind maintainable production systems.

Testing the API

A professional API should also be testable.

For example:

from fastapi.testclient import TestClient

from app.main import app


client = TestClient(
    app
)


def test_health_endpoint():

    response = client.get("/")

    assert response.status_code == 200


def test_prediction_endpoint():

    customer = {
        "tenure": 12,
        "monthly_charges": 89.50,
        "contract": "Month-to-month",
        "internet_service": "Fiber optic",
        "payment_method": "Electronic check",
        "paperless_billing": "Yes",
        "senior_citizen": "No",
        "dependents": "No"
    }

    response = client.post(
        "/predict",
        json=customer
    )

    assert response.status_code == 200

    result = response.json()

    assert "prediction" in result
    assert "churn_probability" in result

This allows us to verify that our API continues to behave correctly as the application evolves.

What Makes This Different From Running a Notebook?

Inside a notebook:

prediction = model.predict(
    customer_data
)

Only your Python environment can easily interact with the model.

After deployment:

application = "Any authorised client"

endpoint = "/predict"

response = "JSON"

Now the model can potentially serve:

Web applications
Mobile applications
CRM systems
Internal company applications
Other APIs
Data platforms

That is why deployment is such an important machine learning skill.

Model Development vs Model Serving

It is useful to distinguish between two separate activities.

Model Development

model_development = [
    "Explore data",
    "Clean data",
    "Engineer features",
    "Experiment",
    "Train models",
    "Evaluate models",
    "Select model"
]

Model Serving

model_serving = [
    "Load trained model",
    "Receive request",
    "Validate input",
    "Transform data",
    "Generate prediction",
    "Return response",
    "Serve application"
]

FastAPI lives primarily in the serving layer.

This is the bridge between machine learning and software engineering.

The Bigger Picture

The eventual production architecture may become much larger.

For example:

production_architecture = {
    "client": "Web or mobile application",
    "api_gateway": "API access layer",
    "ml_api": "FastAPI prediction service",
    "model": "Customer churn pipeline",
    "database": "Prediction and customer records",
    "monitoring": "Performance and health monitoring",
    "logging": "Application and prediction logs"
}

A more advanced system might eventually include:

Docker
PostgreSQL
Authentication
Cloud deployment
CI/CD
Monitoring
Model versioning
Logging
Drift detection
Retraining pipelines
Kubernetes
MLOps platforms

But those systems all build on the same fundamental concept we are learning:

How do we make a trained machine learning model accessible to another application?

What Participants Will Learn.

By the end of the workshop, participants should understand:

Python Foundations

Functions
Classes
Decorators
How these concepts appear inside FastAPI

API Fundamentals

What an API is
Why APIs are important
Requests and responses
GET requests
POST requests
JSON
API endpoints

FastAPI.

Creating a FastAPI application
Defining routes
Creating request models
Using Pydantic
Input validation
Returning responses
Interactive Swagger documentation

Machine Learning Deployment

Saving trained models
Loading trained models
Using Scikit-learn pipelines
Serving predictions
Returning prediction probabilities
Creating /predict

Integration

Sending UI data to FastAPI
Receiving prediction responses
Displaying model predictions
Understanding frontend/backend separation

What You Should Be Able to Explain After the Workshop

By the end, you should be able to explain this entire lifecycle:

Jupyter Notebook

↓

Machine Learning Pipeline

↓

Trained Model

↓

Saved Model Artifact

↓

FastAPI Application

↓

Prediction Endpoint

↓

Frontend Application

↓

Real User

Or, in Python:

complete_ml_journey = [
    "Notebook",
    "Model Training",
    "Model Evaluation",
    "Model Persistence",
    "FastAPI",
    "REST API",
    "Prediction Endpoint",
    "Frontend Integration",
    "Real-World User"
]

From Experiment to Product

There is a significant difference between saying:

I trained a machine learning model.

and saying:

I developed and evaluated a machine learning pipeline, persisted the trained model, built a FastAPI service around it, implemented request validation, exposed prediction endpoints, returned structured responses, tested the service, and connected the model to a user-facing application.

The first demonstrates knowledge of machine learning, while the second demonstrates an understanding of how machine learning becomes part of a software system.

That transition is important for anyone interested in:

Machine Learning Engineering
Data Science
MLOps
Backend Development
Applied AI
Production Machine Learning

Final Thought.

A machine learning model sitting inside a notebook is an experiment, a saved model is an artifact, while model exposed through an API becomes a service.

And a model connected to a usable interface begins to become a product.

machine_learning_evolution = {
    "stage_1": "Experiment",
    "stage_2": "Model",
    "stage_3": "API",
    "stage_4": "Application",
    "stage_5": "Business Value"
}

That is the journey we will explore in this workshop.

From Notebook → To API → To Application → To Real-World Impact

Nice article, Neema. Impressive!

Mwenda Harun Mbaabu — Sun, 28 Jun 2026 16:08:04 +0000

Neema Kirui

Jun 25

The Day I Realized Power BI Isn't Just Pretty Excel: Understanding Data Modelling

#datascience #beginners #womenintech #powerfuldevs

3 min read

Data Science East Africa Big Data and AI Summit -Opening Remarks

Mwenda Harun Mbaabu — Thu, 21 May 2026 22:38:58 +0000

Good morning everyone.

Distinguished speakers, panelists, guests, partners, students, professionals, data enthusiasts, and everyone who has taken the time to be here today — welcome to the Data Science East Africa Big Data and AI Summit.

My name is Harun Mwenda, and as the founder of this initiative, I am truly honored to stand before you today.

First, I want to say thank you.

Thank you for showing up. Thank you for believing in this vision. Thank you for choosing to spend your time in a room full of people who are learning, building, connecting, and thinking about the future of data, AI, analytics, and technology in Africa.

Today is not just another tech event.

Today is about something bigger.

It is about bringing together beginners, students, professionals, data analysts, data engineers, data scientists, machine learning engineers, AI builders, business intelligence developers, and industry leaders into one room — not just to talk about technology, but to talk about opportunity.

The Data Science East Africa Big Data and AI Summit was created to help people understand the data industry, learn from professionals already doing the work, discover modern tools, build practical projects, and see where the future is going.

And that is very important.

Because for a long time, many people have heard words like data science, artificial intelligence, big data, machine learning, analytics, business intelligence, and automation — but for many beginners, these words can feel far away.

They can sound complicated.

They can sound like something reserved for people in big companies, people with advanced degrees, or people who have been in tech for many years.

But the truth is this:

The future of data and AI in Africa will not be built by outsiders alone.

It will be built by us.

It will be built by the students who are starting today.

It will be built by the beginners who are still confused but willing to learn.

It will be built by the professionals who are already working and want to grow.

It will be built by the engineers, analysts, founders, freelancers, researchers, trainers, and problem-solvers who decide that Africa must not only consume technology — Africa must also build technology.

That is why we are here.

We are here because data is no longer just a technical skill. Data is now a language of business, government, healthcare, education, finance, agriculture, climate, security, logistics, and almost every serious decision being made today.

Organizations are asking questions every day:

What is happening in our business?
Why is it happening?
What can we predict?
What can we automate?
How can we serve people better?
How can we reduce cost?
How can we use AI responsibly?
How can we turn information into action?

And behind all those questions, there is a need for skilled people.

People who can collect data.

People who can clean data.

People who can analyze data.

People who can build dashboards.

People who can build data pipelines.

People who can train models.

People who can build AI agents and bots.

People who can explain insights clearly.

People who can solve real problems.

That is the opportunity we are talking about today.

But I also want to be honest.

This field is exciting, but it is not easy.

You will not become a great data analyst, data engineer, data scientist, or AI engineer by only watching videos.

You will not grow by only collecting certificates.

You will not stand out by only copying tutorial projects.

You grow by building.

You grow by practicing.

You grow by asking questions.

You grow by failing, debugging, improving, and trying again.

You grow by working on real problems.

And one of the biggest goals of this summit is to help us move from theory to practice.

That is why today’s program is very intentional.

We will begin by understanding what it means to become a BI Developer and Data Analyst.

We will then look at the future of data, AI, and analytics in Africa.

We will have a panel discussion on careers in data and the future of work, where we will talk about breaking into the industry, growing, monetizing skills, and understanding how AI is changing careers.

We will also hear about competitive data science and AI challenges, freelancing, personal career journeys, building projects that solve real problems, and later in the day, we will have a practical session on building AI agents and bots.

So I encourage you: do not just sit and listen.

Engage.

Ask questions.

Talk to the person seated next to you.

Introduce yourself.

Tell people what you are learning.

Tell people what you are building.

Connect with the speakers.

Connect with the panelists.

Connect with fellow attendees.

Because sometimes, the most valuable thing you leave with is not only knowledge. Sometimes it is a connection, a mentor, a collaborator, a project partner, or even a new opportunity.

To the beginners in the room, I want to say this:

Do not be intimidated.

Everyone who is now experienced was once a beginner.

Every expert once struggled with basic concepts.

Every professional once had a first project.

Every speaker you see today has a journey.

So do not compare your chapter one with someone else’s chapter ten.

Instead, learn.

Take notes.

Ask questions.

Be curious.

Be willing to start small.

Your first dashboard may not be perfect.

Your first model may not be accurate.

Your first project may look simple.

Your first SQL query may break.

Your first Python script may throw errors.

That is okay.

What matters is that you keep building.

To the professionals in the room, I want to challenge you as well.

Let us not only grow individually. Let us also open doors for others.

Mentor someone.

Share knowledge.

Give honest feedback.

Create opportunities.

Recommend someone.

Build communities.

Because the data ecosystem in East Africa will only grow if those who are ahead help those who are coming up.

To our speakers and panelists, thank you for giving your time, your knowledge, your stories, and your experience. Your presence here matters. The people in this room are not only looking for information; many of them are looking for direction. And today, your words may help someone choose a path, start a project, apply for an opportunity, or believe in themselves again.

To everyone who helped organize this event, thank you. Events like this take planning, sacrifice, coordination, pressure, and many moving parts. I appreciate every person who contributed to making this possible.

As we begin, I want us to remember one thing:

Africa does not lack talent.

Africa does not lack ideas.

Africa does not lack problems to solve.

What we need is more execution, more exposure, more collaboration, more confidence, and more spaces like this where people can learn from each other and build together.

That is what Data Science East Africa is about.

It is about community.

It is about skills.

It is about visibility.

It is about building solutions.

It is about preparing people for the future of work.

It is about making sure that as data and AI continue to shape the world, East Africa is not left behind.

So today, I invite you to be present.

Listen deeply.

Network intentionally.

Ask boldly.

Learn practically.

And most importantly, leave this room with a decision to do something with what you learn.

Start that project.

Improve that portfolio.

Reach out to that mentor.

Join that community.

Apply for that opportunity.

Build that solution.

Because the future will not only belong to people who talk about AI and data.

It will belong to people who can use them to solve real problems.

Once again, welcome to the Data Science East Africa Big Data and AI Summit.

Thank you for being here, and I wish all of us a powerful, practical, and inspiring day.

Thank you.

Understanding Data Modeling in Power BI: Joins, Relationships, and Schemas Explained.

Mwenda Harun Mbaabu — Sun, 29 Mar 2026 19:43:41 +0000

Introduction.

Today we will be discussing data modeling in Power BI, one of the most important skills for building effective dashboards.

Many beginners focus on visuals, but good dashboards come from good data models.

In this article, you will learn:

What data modeling is
SQL joins and how they work
Power BI relationships and how they differ from joins
Fact vs Dimension tables
Star, Snowflake, and Flat schemas
Step-by-step how to implement everything in Power BI

What is Data Modeling?

Data modeling is the process of structuring your data so it can be easily analyzed and visualized.

Understanding Linux in Data Engineering: Practical Use Cases Explained Simply

Mwenda Harun Mbaabu — Sun, 29 Mar 2026 12:23:56 +0000

Introduction to power bi

For the past two weeks i have been exploring data engineering at

Introduction

Supermarket Sales and Customer Insights Dashboard — A Practical Power BI Project Guide.

Mwenda Harun Mbaabu — Wed, 04 Feb 2026 12:21:21 +0000

This technical article walks you step by step through a beginner-friendly Power BI project using a real-world supermarket transactions dataset. By the end of this guide, you will know where to download the data, how to prepare it, and how to build an interactive dashboard that answers real business questions.

Project Overview

In this project, you will analyze supermarket transaction data and transform it into an interactive Power BI dashboard. The focus is not just on visuals, but on answering business questions clearly and professionally.

You will act as a Junior Data Analyst, converting raw transaction records into insights that business stakeholders can explore without using spreadsheets.

Dataset Download

You can download the dataset to be used in this project here, https://github.com/LuxDevHQ/Data

Dataset contents:

Three years of supermarket transaction data
Multiple store locations (Australia)
Individual transaction-level records

Columns include:

Product Name
Quantity Sold
Total Sales Amount
Payment Method
Customer Type (Member / Non-Member)
Store Location
Transaction Date

📌 Download the dataset

Business Questions This Project Answers

Before opening Power BI, it is important to understand what questions the dashboard should answer.

1. Sales Performance

What is the total sales amount across all stores?
How do sales trend over time (monthly and yearly)?

2. Product Analysis

Which products generate the highest revenue?
How do apple sales compare across different payment methods?

3. Customer Behavior

How much do members vs non-members spend?
Which customer type contributes more to total revenue?

4. Payment Method Insights

Which payment method is used most frequently?
How does revenue differ by payment method?

5. Store Performance

Which store location generates the highest sales?
How does customer behavior vary by store?

These questions will guide every step of the analysis.

Step 1: Load the Data into Power BI

Open Power BI Desktop
Click Get Data → Text/CSV
Select supermarket_transactions.csv
Load the data into Power BI
Review column names and preview the data

At this stage, do not build visuals yet. First, ensure the data is correct.

Step 2: Data Cleaning in Power Query

Open Transform Data to enter Power Query.

Perform the following actions:

Remove unnecessary or duplicate columns
Fix incorrect data types:
- Dates → Date
- Sales & Quantity → Decimal / Whole Number
Rename columns for clarity (e.g. Total Sales Amount)
Check for missing or inconsistent values

⚠️ Clean data is critical. Poor data quality leads to misleading dashboards.

Step 3: Data Modeling

Once the data is clean:

Confirm all columns have correct data types
Ensure the table structure is logical
No complex relationships are required for this project (single-table model)

This project focuses on analysis and visualization, not complex modeling.

Step 4: Create Beginner-Level DAX Measures.

Create the following measures in Model view or Report view:


DAX
Total Sales =
SUM(supermarket_transactions[Total Sales Amount])

Total Quantity Sold =
SUM(supermarket_transactions[Quantity])

Average Transaction Value =
AVERAGE(supermarket_transactions[Total Sales Amount])

Sales by Customer Type =
SUM(supermarket_transactions[Total Sales Amount])


> ⚠️  These measures will power your KPI cards and charts. 

## **Step 5: Build the Power BI Dashboard**

Create a **1–2 page interactive Power BI dashboard** using the visuals listed below. The dashboard should be designed for **business users**, not technical users.

---

### **Required Visuals**

#### **KPI Cards**
- Total Sales  
- Total Quantity Sold  
- Average Transaction Value  

---

#### **Charts**
- **Bar Chart:** Sales by Product  
- **Bar Chart:** Sales by Store Location  
- **Pie or Column Chart:** Payment Method Distribution  
- **Line Chart:** Sales Trend Over Time  

---

#### **Slicers**
- Store Location  
- Product  
- Customer Type  
- Date  

> 🎯 **Design Principle:**  
> The goal is **clarity, not decoration**. Every visual should answer a specific business question.

---

## **Step 6: Validate Your Results**

Before submitting your work, verify the following:

- Confirm all totals match your **Excel analysis**
- Test all slicers and filters for correct behavior
- Check visual titles, labels, and number formatting
- Ensure visuals respond correctly to user interactions

---

### **Your Final Submission Should Include**

- Record a **4-minute walkthrough video** using **Loom**
- The video should demonstrate a **fully functional Power BI dashboard**
- Briefly explain:
  - The dataset used
  - Key visuals and filters
  - Main business insights and conclusions
- Upload the recording to **Loom** and copy the shareable link
- Submit the **Loom video link via WhatsApp** to **0796 448 232**