The problem: booking is only the beginning
Hamro Futsal was a Tribhuvan University BSc.CSIT academic group project created to explore a more connected futsal-management workflow. The problem was broader than reserving a playing slot. Teams also need a way to organise themselves, schedule friendly matches, record results, and find opponents who can create a reasonably competitive game.
In a manual workflow, booking, team coordination, result records, and match selection often live in different conversations or tools. Our aim was to prototype one system that brought those steps together: venue bookings, team creation, friendly-match scheduling, result submission, and a ranking-led approach to opponent suggestions.
Turning match results into a changing team signal
A central idea in the project was that a team standing should respond to results rather than remain a fixed label. We used an Elo-style rating approach: before a match, the model estimates an expected result from the teams’ relative ratings; after a reported result, the rating is updated according to the gap between expectation and outcome.
This was useful because an unexpected result should carry more information than an expected one. If a lower-rated team beats a higher-rated team, the adjustment should be more meaningful than if the higher-rated team wins as predicted. The resulting ranking was intended as a practical signal for competitive matching, not as a claim of perfect sporting fairness.
Building the workflow around real team actions
The rating logic mattered only if it was connected to a usable product workflow. The prototype included the building blocks around it:
- Account and team workflows for creating or joining teams.
- Futsal booking and schedule views intended to reduce scheduling confusion.
- Friendly-match coordination and recorded match results.
- A ranking-led way to explore potential opponents.
- A Django backend with React-based frontend views and SQLite during development.
The work was iterative. We tested the connection between user flows, match data, and recommendation ideas, then refined the system as a group for the project showcase.
Working as a three-person academic team
Hamro Futsal was developed by Yumesh Ban, Sujal Karki, and Rupesh Acharya. Sujal Karki proposed the initial direction for the algorithm and led the backend work and its refinement, especially around the Elo and recommendation logic. Rupesh Acharya and I worked primarily on the frontend and interface work. I also carried out overall refinement across the product and supported more complex backend implementation where needed.
This division did not mean each part was built in isolation. The rating and recommendation work had to be understandable in the interface, and the frontend workflows depended on the data and endpoints behind them. The project improved through group trial and error, especially when deciding which signals should influence recommendations.
What I handled
- Built and refined major frontend flows for booking, teams, friendly matches, results, and ranking-related experiences with Rupesh Acharya.
- Helped integrate the product end to end, refining user-facing workflows and supporting complex backend work when required.
- Worked with Sujal Karki and Rupesh Acharya to translate an academic algorithm idea into a demonstrable full-stack system.
Outcome: a working academic prototype with clear next questions
The finished project was presented as an academic futsal-management prototype. It demonstrated how booking, team management, reported results, and changing rankings could be linked in one system rather than treated as disconnected tasks.
Its strongest outcome was the learning foundation: we had a working environment for testing how a ranking signal and hybrid recommendations might support friendlier, more competitive match selection. It was not deployed as a verified commercial service, and I do not present it as having measured real venue adoption, payment volume, live matchmaking quality, or production-scale performance.
Reflection
Hamro Futsal taught me that an algorithm is only useful when people can understand the workflow around it. The important question was not only how to calculate a rating, but how a team would create a match, report a result, see the updated information, and use that information in the next decision. It also showed me the value of group iteration: we started with a direction, tested it through implementation, and refined it together.