What the Tool Does
The mentor-mentee matching system pairs people based on declared skills and learning goals. One side of the match offers a skill; the other wants to learn it. The matching logic finds compatible pairs and stores the assignments in a SQLite database.
The interface has two surfaces: a Flask web layer for administration, and a Tkinter desktop GUI for local use. Both talk to the same data layer.
Why the Data Model Matters More Than the UI
The temptation with a small tool is to build the UI first and let the schema emerge from what the interface needs. That approach produces databases that are hard to query and harder to extend.
The schema here was designed before the interface. Three tables: users, skills, and matches. The skills table has a direction column — offer or seek — which keeps the matching logic simple. The matches table records the pair, the matched skill, and a status field that tracks whether the match is active, pending, or declined.
That structure is uncomplicated. It is also the reason the matching query is a single join rather than application-side logic running over a flat list.
The Flask and Tkinter Split
Flask handles the administrative layer: listing all users, reviewing pending matches, updating statuses. Tkinter provides a desktop view for the matching workflow itself.
The split is not architecturally elegant, but it is honest about what the project was. The Flask layer demonstrates HTTP routing and template rendering. The Tkinter layer demonstrates event-driven desktop UI in Python. They are two different evidence types sharing one data model.
What This Project Actually Proves
The evidence here is: relational schema design, Python web routing, desktop GUI construction, and basic matching algorithm implementation. Nothing in that list is inflated.
Small tools do not need to be ambitious. They need to be coherent. A clear data model with a working interface and accurate documentation is more credible than a large project with architectural debt and stretched claims.