DEV Community: Michael Nyawade

I Thought My Machine Learning Project Was Finished. Then I Asked One Question.

Michael Nyawade — Mon, 13 Jul 2026 14:15:28 +0000

When I completed my customer segmentation project, I felt proud of what I had built.

I had worked with nearly half a million retail transactions from the UCI Online Retail dataset. After cleaning the data, I engineered Recency, Frequency, and Monetary (RFM) features, applied K-Means clustering, experimented with different numbers of clusters using the Elbow and Silhouette methods, and visualized the results using PCA.

The outcome made sense.

I could identify VIP customers, loyal high-spenders, mid-value customers, and customers who were at risk of becoming inactive. Better yet, I could explain how each segment could help a business improve marketing, customer retention, and loyalty programs.

I wrote a detailed README, pushed everything to GitHub, and considered the project complete.

Or so I thought.

One Question Changed How I Saw the Project

A few months later, I looked at the repository again and asked myself a question I hadn't considered before.

If I gave this project to a business today, could they actually use it?

The answer was no.

Not because the model was inaccurate.

Not because the clustering was poor.

Simply because everything lived inside a Jupyter notebook.

The only person who could use the project was the person who built it.

Me.

The Notebook Was Never the Product

I think this is a stage many aspiring data scientists go through.

We spend hours cleaning messy datasets, engineering features, comparing models, tuning hyperparameters, and producing visualizations. Once the metrics look good and the notebook runs from top to bottom without errors, it feels like the project is finished.

That's exactly how I approached my customer segmentation project.

From a machine learning perspective, I had done what I set out to do.

From a user's perspective, though, nothing had been built.

Imagine you're the owner of a retail business.

You don't want to open a notebook.

You don't want to install Python or understand K-Means clustering.

You probably don't even care how the customers are segmented.

You simply want to upload your latest sales data and receive a list of VIP customers, loyal customers, and customers who might need a re-engagement campaign.

My project couldn't do that.

It produced useful insights, but only if someone opened the notebook and reran the analysis.

That realization forced me to rethink what "finished" really means.

I Discovered a Gap in My Learning

For a long time, I believed the next step in improving as a data scientist was learning another algorithm.

Maybe I should study gradient boosting more deeply.

Maybe I should explore deep learning.

Maybe I should improve my feature engineering.

Those are valuable skills, but they weren't the gap I had uncovered.

The real gap was everything that happens after the notebook.

How do you package a model?

How do you let someone interact with it without touching your code?

How do you turn analysis into something another person can actually use?

Those weren't questions I had been asking.

Now they seem impossible to ignore.

A Project Isn't Finished Just Because the Analysis Is

Looking back, I don't think my customer segmentation project was a failure.

Far from it.

It taught me how to work with real-world transactional data, engineer meaningful business features, apply unsupervised learning techniques, and communicate insights through visualizations.

Those are valuable skills.

But I've stopped thinking of the notebook as the final product.

I now see it as a prototype.

A place where ideas are tested before they become something useful.

What Comes Next

I'm not writing this as someone who has mastered deployment or MLOps.

I haven't.

In fact, that's exactly why I'm writing this.

I've realized that every machine learning project I've completed has stopped at the notebook stage, and I don't want the next one to end there.

My next challenge isn't building a model with a slightly better score.

It's learning how to take one of the projects I've already built and make it accessible to someone who has never written a line of Python.

Maybe that means exposing it through an API.

Maybe it becomes a simple web application.

Maybe it evolves into something I haven't even considered yet.

I don't know exactly what that journey will look like.

But I know where it starts.

It starts by recognizing that a notebook is an excellent place to build a model.

It just isn't always where the project should end.

Have you ever looked back at one of your machine learning projects and realized it wasn't as "finished" as you first thought? I'd love to hear how you've approached moving beyond the notebook—or whether you're figuring it out too.

I Kept Recreating My Django Superuser Every Time I Switched Computers — Until I Finally Understood What Was Happening

Michael Nyawade — Tue, 02 Jun 2026 12:24:36 +0000

I’ve been building a Django project called SmartDuka, a smart shop management system for small retailers and shop owners. It handles inventory tracking, low stock alerts, dead stock detection, sales tracking, credit sales, and daily business insights.

This is also my first serious Django project.

And for a while, every time I switched from my home laptop to my work laptop, I went through the exact same process:

git clone
python -m venv venv
pip install -r requirements.txt
python manage.py migrate
python manage.py createsuperuser

Then I would open the admin panel and start entering products, customers, and sample sales all over again.

Every. Single. Time.

At first, I thought this was just part of working with Django. But eventually I realized I wasn’t actually understanding the relationship between:

my code
migrations
and the database itself

This article is basically the explanation I wish someone had given me earlier.

The Mistake I Wasn’t Really Making

To be fair, I was doing one important thing correctly:

db.sqlite3

was inside my .gitignore.

For a good reason SQLite databases are local files and usually shouldn’t be committed to Git.

So technically my workflow looked “correct.”

The problem was this:

I assumed migrations would somehow preserve my data across machines.

They don’t.

What Django Migrations Actually Do

This part finally clicked for me after some frustration.

When you run:

python manage.py migrate

Django recreates the database structure, not the actual records inside it.

So migrations restore things like:

tables
columns
relationships
constraints

But they do not restore:

superusers
products
inventory
sales records
customers
suppliers

That data lives inside the database itself.

And in SQLite, that database is literally one file:

db.sqlite3

Once I understood that, everything made sense.

Why I Had to Keep Recreating My Superuser

Because every new machine was getting:

fresh empty database

After migrations, Django had the tables it needed, but there were no actual records inside them yet.

So naturally:

no users existed
no inventory existed
no sales existed

I wasn’t losing my code.

I was losing my database state.

The Different Solutions I Considered

Once I understood the problem properly, I realized there are several ways developers approach this.

1. Recreate Everything Every Time

This was my original workflow.

It technically works, but only for tiny projects.

Once your app starts accumulating meaningful data, this becomes painful very quickly.

2. Commit `db.sqlite3` to Git

I considered this briefly.

It solves the syncing issue, but introduces other problems:

binary file conflicts
messy Git history
merge problems
potential security risks

For a real project, this didn’t feel right.

3. Use Fixtures

Django supports:

python manage.py dumpdata
python manage.py loaddata

which export and import data as JSON fixtures.

This is actually pretty useful for:

demo data
seed data
lookup tables

But for constantly changing business data like inventory and sales, it felt awkward as the main solution.

4. Copy `db.sqlite3` Between Machines

This ended up being the most practical short-term solution for me.

Instead of recreating everything, I simply keep the latest SQLite database and transfer it between machines manually.

That preserves:

my superuser
inventory records
customers
sales history
everything else

The workflow now looks more like this:

git pull
pip install -r requirements.txt
# copy latest db.sqlite3
python manage.py migrate
python manage.py runserver

Much better.

The Important Detail About Migrations

One thing I learned here:

The correct order is:

copy db.sqlite3
then run migrations

Not the other way around.

Why?

Because migrations should update your existing database schema if new model changes were added.

For example, if yesterday my Product model had:

name = models.CharField(max_length=100)

and today I added:

price = models.DecimalField(...)

then running:

python manage.py migrate

updates the copied database safely.

That’s exactly what migrations are designed for.

The Bigger Realization

At some point, I realized SmartDuka started behaving like a real system.

And once that happens, things like:

persistence
synchronization
database strategy
backups
scalability

suddenly become important.

That transition caught me by surprise a little.

What I’m Planning Next

Right now I’m still using SQLite during development because it’s simple and fast.

But I can already see that eventually I’ll need to move toward PostgreSQL, especially because SmartDuka deals with:

transactions
inventory
analytics
credit management
reporting

At that point, having a shared database instead of manually copying SQLite files will make much more sense.

But honestly, understanding why I was recreating my superuser every time was already a huge learning moment.

Final Thoughts

One thing I’m learning while building real projects is that software development isn’t only about writing features.

Sometimes the biggest lessons come from workflow problems.

This was one of them for me.

If you’re new to Django and you’ve ever wondered:

“Why do I keep losing my data even after running migrations?”

hopefully this article saves you a few hours of confusion.

Why Adding a Unique SKU Field Broke My Django Migration

Michael Nyawade — Sun, 10 May 2026 08:05:18 +0000

In building projects using Django, one thing that I have realized about database migrations is that things may appear simple until the moment one alters an existing model.

For example, in developing an inventory management app for my project recently, I experienced a migration problem, which, although small, helped me understand how migrations work within Django and in particular, when adding unique constraints to existing databases.

I would like to document this problem since someone else may have experienced the same thing.

The Initial Inventory Model

At the beginning, my Product model was simple.

from django.db import models


class Product(models.Model):
    name = models.CharField(max_length=100)
    buying_price = models.DecimalField(max_digits=10, decimal_places=2)
    selling_price = models.DecimalField(max_digits=10, decimal_places=2)
    stock_quantity = models.PositiveIntegerField(default=0)
    low_stock_threshold = models.PositiveIntegerField(default=5)
    created_at = models.DateTimeField(auto_now_add=True)

    def __str__(self):
        return self.name

After creating the model, I generated and applied migrations:

python manage.py makemigrations
python manage.py migrate

I also registered the model in admin.py:

from django.contrib import admin
from .models import Product


admin.site.register(Product)

Everything worked perfectly.

I created a superuser, logged into the Django admin panel, tested the model, and there were no issues.

Updating the Inventory App

As the project evolved, I realized the inventory system needed product categories and SKU support.

So I updated models.py.

from django.db import models


class Category(models.Model):
    name = models.CharField(max_length=100, unique=True)

    class Meta:
        verbose_name_plural = "Categories"

    def __str__(self):
        return self.name


class Product(models.Model):
    category = models.ForeignKey(
        Category,
        on_delete=models.CASCADE,
        related_name='products'
    )

    name = models.CharField(max_length=100)
    sku = models.CharField(max_length=50, unique=True)

    buying_price = models.DecimalField(max_digits=10, decimal_places=2)
    selling_price = models.DecimalField(max_digits=10, decimal_places=2)

    stock_quantity = models.PositiveIntegerField(default=0)
    low_stock_threshold = models.PositiveIntegerField(default=5)

    created_at = models.DateTimeField(auto_now_add=True)

    def profit_per_item(self):
        return self.selling_price - self.buying_price

    def is_low_stock(self):
        return self.stock_quantity <= self.low_stock_threshold

    def __str__(self):
        return self.name

I also updated admin.py:

from django.contrib import admin
from .models import Category, Product


admin.site.register(Category)
admin.site.register(Product)

Then I created new migrations.

At this point, I expected everything to work normally.

Instead, Django threw a migration error.

The Error I Encountered

When I ran:

python manage.py migrate

I got this:

django.db.utils.IntegrityError:
UNIQUE constraint failed: new__inventory_product.sku

At first, I was confused.

The sku field looked correct:

sku = models.CharField(max_length=50, unique=True)

So why was the migration failing?

What Was Actually Happening

After looking into it more carefully, I realized the issue was related to existing database records.

Before adding the sku field, the Product table already existed in the database.

When Django attempted to apply the migration, SQLite internally tried to:

Create a new version of the table
Copy the old data into the new table
Apply the new constraints

The problem was that the new sku field had unique=True.

Existing records in the database didn’t have SKU values yet.

As SQLite tried moving data into the new table structure, duplicate empty values conflicted with the unique constraint.

That’s why the migration failed.

How I Fixed It

Since I was still in the development stage of the project, I decided to reset the database completely.

Here’s what I did:

1. Stopped the Development Server

CTRL + C

2. Deleted the SQLite Database

db.sqlite3

3. Deleted Old Migration Files

I deleted the migration files inside the app’s migrations folder, except:

__init__.py

4. Recreated Migrations

python manage.py makemigrations

5. Applied Migrations Again

python manage.py migrate

6. Recreated the Superuser

python manage.py createsuperuser

After that, everything worked correctly.

What I Learned

This experience taught me an important lesson:

Adding unique fields to existing Django models can break migrations if the database already contains records.

Even though the code itself may look correct, the migration process also depends on the current database state.

I also learned that:

Resetting the database is acceptable during early development
It is not a good solution for production systems
Database schema changes should be planned carefully
Unique constraints require special attention when existing data is involved

A Better Production Approach

If this were a production project, deleting the database would obviously be a bad idea.

A safer approach would be:

Add the field without unique=True
Populate existing rows with unique values
Then apply the unique constraint in a later migration

That prevents conflicts with existing records.

Final Thoughts

This wasn’t the biggest bug I’ve encountered in Django, but it was one of those moments that helped me understand migrations better.

Sometimes small errors teach the most useful lessons.

If you’re learning Django and run into migration issues after modifying models, don’t panic immediately. In many cases, the problem is related to how existing database records interact with the new schema changes.

Hopefully this saves someone else a few hours of confusion.

DEV Community: Michael Nyawade

I Thought My Machine Learning Project Was Finished. Then I Asked One Question.

One Question Changed How I Saw the Project

The Notebook Was Never the Product

I Discovered a Gap in My Learning

A Project Isn't Finished Just Because the Analysis Is

What Comes Next

I Kept Recreating My Django Superuser Every Time I Switched Computers — Until I Finally Understood What Was Happening

The Mistake I Wasn’t Really Making

What Django Migrations Actually Do

Why I Had to Keep Recreating My Superuser

The Different Solutions I Considered

1. Recreate Everything Every Time

2. Commit db.sqlite3 to Git

3. Use Fixtures

4. Copy db.sqlite3 Between Machines

The Important Detail About Migrations

The Bigger Realization

What I’m Planning Next

Final Thoughts

Why Adding a Unique SKU Field Broke My Django Migration

The Initial Inventory Model

Updating the Inventory App

The Error I Encountered

What Was Actually Happening

How I Fixed It

1. Stopped the Development Server

2. Deleted the SQLite Database

3. Deleted Old Migration Files

4. Recreated Migrations

5. Applied Migrations Again

6. Recreated the Superuser

What I Learned

A Better Production Approach

Final Thoughts

2. Commit `db.sqlite3` to Git

4. Copy `db.sqlite3` Between Machines