In Part 1, I talked about the post-pandemic slump, how I rebuilt my discipline, and how that led to an award-winning project.
This post is the second and final part of that story: how we built my final course project (TCC)—from the first half-baked ideas to the final delivery and presentation.
A classroom split in two
At my ETEC, our Systems Analysis and Development class had around 40 students, but the lab rooms couldn’t fit everyone comfortably.
So the class was split into Side A and Side B—20 students each.
- odd numbers → Side A
- even numbers → Side B
My name starts with V, which put me near the bottom of the list… and on Side A (this was still pre-pandemic).
It sounds like a tiny detail, but it mattered later.
Watching TCCs during the pandemic
During the pandemic, we had a chance to watch TCC presentations from older classes finishing the course. I remember sitting there, in front of recorded videos and live chats, trying to understand what a “good” final project looked like.
I asked teachers questions in the chat. I watched a bunch of projects. Little by little, I got a clear picture of the challenge:
A TCC wasn’t “just an assignment”.
It was a full project, with planning, scope, documentation, presentation, and delivery—and I’d have less than a year to study and build something worth defending in front of a panel.
That reality hit me early.
And honestly? It scared me in a good way.
Back to in-person
When we returned to in-person classes in 2022, the TCC conversations started almost immediately. This would be the first fully in-person TCC cycle in two years.
The rules were pretty straightforward:
- Build a project (real or fictional) for a business/institution
- Don’t charge for it
- Apply what we learned over the three years of the course
Simple on paper.
At the time, I wanted to do the project alone—not because I dislike teamwork, but because I wanted to prove to myself I could carry a full project end-to-end.
But there was a problem:
Teams were mandatory.
Teachers even said we could switch between Side A and Side B to form teams with people we worked well with. That’s when that classroom split from earlier came back.
So I moved to Side B, grouped up with four friends, and we created our team:
Frog Developers (yes, there’s a story)
We named ourselves Frog Developers, and the origin is… extremely high school.
Some students had a group they proudly called something like “the rat squad”. We had a tiny rivalry with them.
So to mock it, our friend group became “the frog squad”. And when it came time to form a serious TCC team, Frog Developers was basically:
A few “frog squad” friends who decided to ship a project together.
Not exactly a startup origin story… but it worked.
The idea graveyard
Before we found our final project, we went through the classic phase:
too many ideas, too little time.
Idea #1: a Brainly answer site (yeah… no)
My first idea—still during the pandemic—was a dynamic website that would query Brainly’s API and return answers to academic questions for students.
I killed that idea pretty quickly. For obvious reasons.
Also, it’s funny to think that about two years later, AI would basically become the “same thing” on a completely different scale. Life moves fast.
Idea #2: a condo administration system (too big)
My second idea was more legit: build a condo management system for a family friend.
The users (building managers, caretakers, supervisors) would have daily task checklists like:
- checking fire extinguishers
- elevator maintenance
- drainage system routines
- general inspections
It was useful… but the scope was massive. The more we mapped it, the clearer it became:
We wouldn’t finish it in time.
So we dropped it.
And that decision taught me one of the most underrated project skills:
Scope is everything.
Learning Vue at the right time
Around that period, I decided to learn a framework that was getting really popular: Vue 3.
Vue felt different to me. More direct. More intuitive. Less friction than what I’d felt with React at the time.
And most importantly:
It felt like something I could use to build fast without sacrificing structure.
So I committed to it.
And that choice ended up saving our project.
The final idea
After a while, one member of the group brought a new idea:
Build an inventory control system for a natural products store owned by the family of another student in the school.
That’s when everything clicked.
We defined something practical and clear:
- Desktop + mobile system for internal stock control and daily operations
- A website for customers to check purchase-related information
The problem?
I was the only developer in the team.
And we had less than three months left.
But we looked at each other and basically said:
Alright. Let’s do it anyway.
Building under pressure
Once the design was ready and I felt comfortable with Vue 3, I went into full execution mode.
Somehow, I managed to finish the interface in less than one month.
Then the real work started: turning screens into a product.
Over the following days, I focused on the parts that make a system feel real:
- cloud data persistence
- state management
- routing
- portability to desktop and mobile
It wasn’t glamorous. It was a lot of debugging, a lot of late nights, and a lot of “why is this breaking now?”
But it moved.
And each day it moved more.
The presentation
When we were just a few days away from presenting, we shifted into rehearsal mode. We practiced the delivery, planned who would say what, polished the narrative, and tried to make the presentation feel confident—not improvised.
Then we had one final idea.
Since the project was for a natural products business, we decided to bring small succulent seedlings as a gift for visitors and judges.
It was a small detail, but it made the room warmer.
More human. Less “school assignment.” More “real project.”
And in the end?
It worked.
The teachers evaluating us said it was one of the best TCC presentations they had seen in 10 years.
Their words.
I still remember that moment because it didn’t feel like a grade.
It felt like recognition.
The lesson that closed the chapter
Looking back, the technical part mattered—but the real lessons were bigger:
- A good project is a scoped project;
- The right tools at the right time are leverage;
- Execution beats perfect planning;
- Presentation is part of the product.
But the biggest takeaway of that year wasn’t even technical.
It was personal.
Between the post-pandemic slump, the award-winning prototype, and the final project under pressure, I rebuilt something I thought I had lost: discipline, focus, and the ability to deliver.
And that’s why I like to revisit this story.
Because none of it happened by accident.
It happened because I made a decision back in 2021: to stop running from discomfort and start building a future I actually wanted.
Effort pays you back.
Sometimes with skills. Sometimes with confidence. Sometimes with recognition.
But it always pays you back.