-
-
Creating an account
-
the log in page
-
Finding a conductor page on the student dashboard
-
requesting a lesson
-
Upcoming lessons section on the student dashboard
-
once the teacher confirms a lesson
-
teacher's dashboard on the upcoming lessons
-
Admin management
-
Admin dashboard
-
where it was built
-
after requesting a lesson on the student dashboard
About the Project: Tutti
💡 What Inspired Me
Devlance 2026 challenges builders to transform ideas into "scalable solutions" and solve "meaningful challenges across industries". As a musician who plays the trumpet and piano, I experience these challenges firsthand. The freelance music and education industry suffers from severe administrative fragmentation. Gigs, lessons, and rehearsals are scattered across different messaging apps, and collecting payments often involves awkward follow-ups and delays.
I realized there was a massive need for a unified platform. I was inspired to build Tutti to provide "practical business value" for independent educators by centralizing schedules and automating payments, perfectly aligning with the call for solutions that offer "measurable outcomes" in the education and skills sector.
🛠️ How I Built It
To ensure "strong engineering and execution quality", I built Tutti as a full-stack web application using a robust and practical tech stack.
- Backend Architecture: I utilized Python and the Django framework to manage the core logic, user authentication, and database routing. The system employs role-based access control (Students, Teachers, Superusers) to manage the workflow.
- Database: I used SQLite3 for rapid local prototyping, but designed the Django ORM models with a clear migration path to PostgreSQL to ensure the application meets the hackathon's core evaluation metrics for "scalability".
- Frontend: The user interface is structured with HTML, CSS, JavaScript, and Bootstrap templates to create a clean, professional CRM dashboard that emphasizes "real-world usability".
- Payment Integration: I integrated the Safaricom M-Pesa Daraja API (via
django-daraja) to handle live mobile money transactions, satisfying the need for "reliability, trust, and professional relevance" in digital payments.
🚧 The Challenges I Faced
The most significant technical challenge was engineering the end-to-end M-Pesa payment flow on a local development server. Because Safaricom's network relies on webhooks (callbacks) to confirm a successful STK push transaction, it cannot communicate directly with localhost.
To solve this, I had to implement a secure tunneling service (ngrok) to expose my local server to the internet, dynamically updating the callback_url parameter in my Django views to route the Safaricom POST requests back to my application. Additionally, designing the state-machine logic to accurately track a lesson's lifecycle (from REQUESTED to SCHEDULED, PENDING_PAYMENT, and finally PAID) required strict database relationship management to ensure "execution clarity".
🧠 What I Learned
Building Tutti taught me how to architect a "usable, scalable, and practical solution" from the ground up. I gained deep, hands-on experience in:
- Handling external API integrations and asynchronous webhooks.
- Building a multi-role user architecture within Django.
- Simulating production-grade environments locally using secure tunnels.
Furthermore, analyzing the financial flow of the app taught me the importance of quantifiable metrics. Ultimately, this project reinforced that "technology without execution has limited value", and true innovation lies in solving real operational problems.
Built With
- css
- django
- django-daraja
- html5
- javascript
- postgresql
- python
Log in or sign up for Devpost to join the conversation.