This semester, we didn’t just “build a student tool.” We shipped Mathiné—and learned the hard truth that adoption isn’t about features alone; it’s about access. If a product lives outside a student’s normal workflow, even great work gets ignored – not because it isn’t useful, but because it’s extra: extra tabs, extra logins, extra steps, extra mental load. That realization reshaped our endgame: less “add more functionality,” more “put Mathiné where students already are.”
What we shipped
By the end, Mathiné finally looked and felt like the product we imagined in September – less a backlog of “someday” and more a coherent planning stack that could actually fit into a student’s week. We shipped improvements that made planning feel connected and usable (shared calendars, subtasks, time-slotting, a refreshed landing flow) and pushed toward Brightspace-driven automation so students weren’t forced to re-enter what the system already knows. Our work stopped being about adding more tools and became about reducing friction so students could use it inside their existing routine.
What we learned building inside UVic
Building inside a university ecosystem forced a different kind of product maturity: stakeholders aren’t just supporters, they operate within approvals, dependencies, timelines, and governance that are very real – and often non-negotiable. Those constraints didn’t just slow us down; they changed how we built – more requirements to satisfy, more coordination to do, and more discipline in how we scoped, tested, and communicated changes.