Three Days, One Idea | Building a Real Learning App

This project didn’t start with architecture diagrams.

It started at the kitchen table.

We were talking as a family about what I had been building in a lab environment — a 3-agent Agentic AI system. I explained how it felt a bit like “training” a GPT for a specific purpose: defining roles, constraints, expected outputs.

My daughter listened.

She’s preparing for her advanced digital culture exam.
And she’s also studying to become a dog groomer.

Then she said:

“I tried training a GPT with my study materials… but it keeps doing something different every time.”

And for a second, I thought:
Of course it does.

Large language models are probabilistic.
Great at generating answers.
Not designed to enforce structure.

That thoughts could have led anywhere.

But at that moment, I wasn’t just coming from building an Agentic AI pipeline.

I was deep in strengthening my Python skills.
Revisiting forgotten patterns.
Practicing object-oriented design.
The day before, I had just finished a small duck typing exercise.

And suddenly I thought:

Why don’t we just build our own learning tool?

You bring the content.
I’ll build the system.

Her eyes lit up.

So did mine.

When Enthusiasm Hits

When that kind of idea hits me, I’m unstoppable.

GitHub Desktop opened.
New branch created.
Keyboard on fire.

Let’s design card objects.
Let’s build a game engine that has card objects.

Wait.

That’s composition.

That tiny OOP “aha” moment happened in real time.

The structure started forming:

• DogCard objects
• FlashcardGame engine
• Stats tracking
• Adaptive weighting logic

Of course, I ran into bugs.

Simple ones.
Complicated ones.

Something didn’t work.
I debugged.
I discussed the logic with ChatGPT.
It suggested.
I argued back.
It counter-argued.
We refined.

However, ChatGPT wasn’t a magic wand.
It didn’t build the app for me — it helped me think.

For instance, when I got stuck in a messy function,
it was like having a teammate to review the logic.

And after about 1.5 days:

The CLI app worked.

My daughter sat at my computer.

There were no images yet — just filenames.

And she was excitedly typing dog breeds, coat types, grooming methods.

That was the first milestone.

It was real.

From CLI to Flask

The next day, I wanted to give it a proper coat.

Time to turn a terminal script into a web application.

Because the engine was already separated from the interface,
Flask became a thin layer on top.

That decision — separating logic from presentation — paid off immediately.

The engine stayed untouched.

I added:

• Authentication
• Session handling
• Persistent per-user state
• Save / load management
• Template rendering
• Static assets

By the evening, the app looked beautiful.

But beautiful is not the same as finished.

UI elements needed alignment.
Styling needed refinement.
Edge cases needed testing.

And then came the real mountain:

Deployment.

The Deployment Mountain

This was my third deployed app recently.

And every time, I collided with the same invisible wall:

WordPress + custom Flask app
Multiple domains
Subdomains
Folder structures
Passenger
Virtual environments
WSGI paths

Mappa here.
App there.
Web server somewhere else.

Debugging became detective work.

This time, though, something changed.

We didn’t just patch around the issue.

We found the root cause.

Understanding how routing, rewrite rules, and environment paths truly interact under a shared hosting setup with multiple domains changed everything.

The “big book of deployment rules” I had been searching for?

It doesn’t exist.

You build it through mistakes.

And this time, the app integrated cleanly — exactly as it should.

What This Project Really Gave Me

Technically, I strengthened:

• Object-oriented design (composition in practice)
• Clean separation of concerns
• Stateful web architecture
• JSON persistence
• Session management
• Authentication flows
• Adaptive weighting logic
• Deployment debugging
• Production integration

But something more important happened.

This is the first piece of software I built that:

• wasn’t just for me
• solves a real need
• is actively used
• is shared with others

My daughter now uses it to study.

She shows it to her classmates.

And it helps.

That matters more than any refactor ever could.

View source code on

The Most Beautiful Part

Three days earlier, this didn’t exist.

From the first Python class
to the last deployment click

I built it.

Alone.

And not just as an experiment.

But as a real tool.

That’s what I’m proud of.

Not the Flask routes.
Not the CSS polish.
Not even the deployment.

But the fact that an idea born in a family conversation
became a working system in three days.

And along the way, I:

• reactivated forgotten coding instincts
• deepened my OOP intuition
• strengthened debugging skills
• improved deployment understanding
• and built something meaningful