Most thesis projects are built to be defended.
They start as an idea, turn into a proposal, become a document, and end as a presentation. After the panel signs the paper, the project quietly stops there.
When we started MySched, that was the plan.
Build the app. Write the chapters. Pass the defense.
But somewhere in the middle of fourth year, it stopped being just that.
It Started With a Simple Goal
MySched began as an OCR-based mobile app to scan printed registration cards and turn them into digital schedules. On paper, it sounded clean and straightforward.
Scan → Extract text → Generate timetable → Set reminders.
We focused on making the feature work. The OCR had to read correctly. The schedule had to display properly. Notifications had to trigger at the right time.
During early testing, everything looked good.
But we were testing in controlled situations. Stable Wi-Fi. Clean registration cards. Our own devices.
Real life was different.
The Moment We Took It Seriously
Before final defense. Before we felt fully "ready." We let actual students use it.
That changed everything.
Suddenly, it wasn't about whether the OCR could extract subjects. It was about:
- What if the card is folded?
- What if lighting is bad?
- What if two subjects overlap?
- What if the student edits the wrong field?
We realized that features are only half of a system. The other half is how people experience them.
Design Became More Than Colors
In the beginning, we were focused on making the app look clean. Consistent spacing. Clear typography. Organized layouts. A modern feel.
But once real students used it, we saw something deeper.
If a button feels confusing, students hesitate. If a screen loads without feedback, they tap multiple times. If an error message sounds technical, they panic.
So design stopped being about aesthetics.
It became about clarity.
We simplified layouts. Reduced clutter. Made the primary action obvious. Disabled buttons during processing. Added loading indicators that actually meant something.
We learned that good design prevents mistakes before they happen.
Notifications Changed Our Thinking
Reminders were one of the core features. But reminders are fragile.
If a student misses a class because the app failed silently, that is not a small bug.
We had to consider:
- What if the device is offline?
- What if permissions are denied?
- What if time zones change?
- What if the app is force-closed?
This forced us to think beyond "does the notification fire?" and instead ask, "Can students trust this?"
Trust became more important than features.
Real Users Exposed Real Problems
Students forgot passwords. They changed phones. They logged in and out frequently. They tapped buttons multiple times. They used older devices with slower performance.
We started seeing small cracks in flows we thought were solid.
Authentication felt simple at first, but in real usage it had edge cases. Sessions expired mid-action. States became inconsistent. Network delays created confusion.
So we refined everything.
We made interactions predictable. We handled delays more gracefully. We assumed networks would fail.
The app slowly moved from "it works" to "it survives."
Accessibility and Consistency
Another shift happened when we started thinking about accessibility more intentionally.
Touch targets had to be large enough. Text contrast had to be readable in sunlight. Animations had to feel smooth but not distracting.
Small UI decisions matter more when students use your app daily between classes, sometimes under pressure.
We stopped designing for screenshots. We started designing for daily use.
Testing Became About Real Life
In the early phase, we tested features.
Later, we tested scenarios.
What happens if a student scans the wrong card? What happens if extraction fails halfway? What happens if the internet disconnects during sync? What happens if they reinstall the app?
We tested messy situations, not ideal ones.
That changed the quality of the system more than any single feature ever did.
The App Store Changed the Stakes
When we prepared to submit to the Play Store and App Store, the project felt different.
You cannot push unstable updates when people rely on the app. You cannot break schedules accidentally. You cannot treat users like testers anymore.
Updates needed discipline. Changes required care. Backward compatibility mattered.
At that point, MySched stopped feeling like a school requirement.
It felt like responsibility.
The Real Lesson
The most important lesson was not technical.
Releasing MySched early forced us to grow from students building a project into students managing a real product.
We learned that:
A feature working is not the same as a feature being reliable. A clean UI is not the same as a clear experience. A demo flow is not the same as daily usage.
We stopped optimizing for panel impressions.
We started optimizing for stability, clarity, and trust.
Looking Back
The app is still evolving. It is not perfect. But it is real.
If we had kept MySched inside a document until defense day, we would have passed with a working thesis.
By letting students actually use it, we learned what it means to build something that lives beyond a presentation.
That is why we chose to release it early.
Not to impress.
But to learn the hard way.