A thesis product can pass review with strong slides, a good demo, and a coherent defense. That proves the idea can be explained. It does not prove the system can survive real usage.
MySched changed the moment students started relying on it in daily routines. That transition exposed the gap between "demo-ready" and "user-ready."
1) Real usage surfaced the edge cases immediately
In controlled demos, OCR quality is evaluated on ideal samples. In the field, inputs are messy: bent cards, uneven lighting, shaky capture, old devices, and unstable networks. Each condition adds failure modes that rarely appear in presentation scenarios.
2) Reliability became the primary product feature
A reminder workflow is not just interface behavior, it is a user promise. When reminders fail, users do not just lose data, they lose confidence in the product. The same happened with auth and sync: flows that looked stable in demos fractured under reinstalls, interrupted sessions, and reconnect scenarios.
We shifted focus from adding features to hardening behavior:
- explicit loading and retry states,
- predictable re-entry points,
- and clearer failure handling paths.
3) Design priorities moved from polish to clarity
Polished visuals help, but stressed users prioritize orientation. Every critical screen had to answer four questions quickly:
- what is happening now,
- what just happened,
- what failed,
- and what to do next.
That clarity work did more for usability than visual refinement alone.
4) Shipping raised the cost of ambiguity
Once real users were active, "we can patch later" became expensive. Small local changes produced cross-feature regressions across reminders, account state, and sync behavior. Our process had to mature with the product: assume uncertainty, make failure paths explicit, and test realistic usage patterns.
What changed for me
The project stopped being a thesis artifact and became an operational responsibility. At that stage, the only metric that matters is simple: does it still work when real life is noisy.