Scholar Desk : The Ego Issue
🎓 I Built ScholarDesk During My Exam Preparation and It Has 16 Real Users Today
Hello everyone! Welcome back to Mayur's Tech Journey. 🚀
Some stories begin with a plan. This one began with an email from a stranger.
I want to tell you about ScholarDesk. About how it started as a reaction, turned into a CLI tool running quietly in a terminal, then became a full stack web application, then got deployed live on the internet, and then ended up in the hands of 16 real users who are not engineers, not my teammates, not people who owe me anything. Just real people who found it useful.
But before I get to any of that, let me set the scene properly. Because the context is everything here.
📖 The Scene: PL of End Semester Exams
Engineering students in Maharashtra know what "PL" feels like. The Preliminary Leave period before end semester exams is supposed to be sacred study time. Notes out. Syllabus open. Revision mode fully activated.
I was in that exact period. End sem exams of my First Year Second Semester were approaching. June 5th is the date. Three days from now as I write this. The pressure was real. And then my phone showed a new email notification.
I opened it.
The email was from someone anonymous. They were talking about a project I had built in my first semester. A frontend website called the Student Task Manager. It was one of my early projects. Simple HTML, basic CSS, nothing connected to a backend, nothing storing any real data. Just a beginner doing beginner things and feeling proud of it at the time.
The email was suggesting that the project needs improvement and this person would improve my project for me. And that I would have to pay for it.
I sat with that for a moment.
And then something in me just said: why would I pay someone to improve something I built, when I can improve it myself? And you know, I have an Ego issue right from my birth.
Email :
Hi Mayur,
Your Student Task Manager project deployed on onecompiler is a broken project in 2 obvious ways :
1) No storage of tasks: After logging out, the tasks are not stored, why anyone would use it then.
2) The UI is ugly and barebones : It looks like a 1-hour tutorial project. Nobody's going to use this over Google Keep.
Right now it's not portfolio-worthy.But it could be.
I fix projects like this for students. With minimal fees, I'll add proper storage, authentication and rebuild the UI so it doesn't look like a dead assignment.
Want to actually make this solid or leave it as is? Let me know if you're serious about connecting.
That thought, right there in the middle of exam preparation, is how ScholarDesk was born.
💭 The Decision That Made No Sense (and Every Sense)
Here is the honest version of what happened next. I decided to build a complete, backend connected, database driven, fully functional version of my old student task manager. During exam preparation. With exams days away.
People would probably say that was a bad idea. Maybe it was. But I have always believed in something: pressure accelerates learning in a way that comfort never can. I had experienced this during 12th standard when I was preparing alone, with limited resources, under the weight of expectations nobody around me could fully understand. I experienced it again during the hackathon when our app crashed and we had to fix it in front of a judge.
Pressure does not just test you. It teaches you. Fast.
So I opened VS Code and started building.
GITHUB : https://github.com/engineermayur-07/ScholarDesk-Web-App
LIVE AT : https://scholardesk.pythonanywhere.com/
💻 Phase One: The CLI That Taught Me Everything
Before building the web app, I made a decision that turned out to be one of the smartest of this entire journey.
I built a terminal based command line interface first.
The idea was simple. Before I touch any frontend, before I write a single HTML tag, I want to make sure the core logic works completely. Authentication. Database. Notes. Tasks. Everything. If it runs properly in the terminal, then converting it to a web app becomes much cleaner.
So I started with SQLite.
I had never properly worked with a database before this. I had heard about databases in lectures, understood the concept theoretically, but never sat down and actually written queries to create tables, insert rows, fetch data, and manage users. SQLite gave me a perfect starting point because there is no server to set up. It is just a file on your computer, and you talk to it with Python.
I learned the queries. CREATE TABLE. INSERT INTO. SELECT FROM. WHERE clauses. I implemented it all inside the CLI.
And then something happened that I was not fully prepared for.
I opened the SQLite browser. It is a small tool that lets you see the actual contents of your database file visually, like a spreadsheet. I had just registered a test user through my terminal. I ran my program, typed in a name, a password, and pressed enter.
I opened the browser.
There was my user. Sitting in the table. In the database file.
I know this sounds like a small thing. But when you are a student who has only ever seen data disappear when a program closes, seeing your data actually persist, actually be stored, actually be there when you look for it, that is a completely different feeling. It is the first time code feels like it is doing something real.
I stared at that screen for a while.
🔐 Authentication: The Moment I Felt Like a Real Developer
After the database was set up, I built the authentication system.
Registration. Login. Logout. Password reset through contact number verification. Session handling. These are things every web app has. But building them yourself, from scratch, understanding why each piece exists and how each piece connects, is a different experience from using a library that handles it for you.
The moment I registered a test account through my CLI and then successfully logged in using those same credentials, something shifted in how I thought about myself as a developer.
Registration means writing data into the database. Login means reading that data back, comparing the password, and returning a session token. These are concepts. But when you have built them yourself, they stop being concepts and become things you genuinely understand at the level of cause and effect.
I pushed this CLI version to GitHub as Students-ToolKit. It is all Python, no frontend, just a terminal interface with real authentication and a real database behind it. That repo is still there if you want to look at the foundation before the building was built on top of it.
🌐 Phase Two: The Web App Begins
Once the CLI was complete and working, I started on the web app.
I used Flask. For those who have not used it, Flask is a Python web framework that lets you define routes and build web applications without the massive overhead of something like Django. It suited what I was building perfectly.
The first time I loaded a styled page in the browser, there was a rush that I genuinely did not expect. This is something that is hard to explain to someone who has not experienced it. You have been staring at terminal output for days. Everything is text. And then suddenly there is color. There is a button that actually looks like a button. There is a layout that looks like something a person would actually use.
High dopamine is the exact right phrase for that moment.
And once that first page came together, the energy to keep building became almost automatic. Every new page completed felt like a small victory. Every feature that worked felt like a reason to keep going.
🤝 Arjun B. Kadam: The Contributor Who Changed the Game
Somewhere while I was building the frontend, I hit a wall. The project was feeling big. Really big. And time was not on my side with exams approaching. So I reached out to Arjun B. Kadam.
Arjun is a classmate and someone I had been coding alongside this semester. I asked him for help, and he said yes. And what he brought was not just code. He brought a mindset I needed.
Arjun pushed me to think about edge cases. What happens when a user submits an empty form? What happens when someone tries to navigate to a protected page without being logged in? What happens when session data is missing? These are the questions that separate a working prototype from a real application that can actually survive contact with real users.
But the biggest thing Arjun introduced me to was working with multiple branches on GitHub.
Before this project, I had always worked on main. One branch. One version. Whatever I pushed went directly to the project. That works fine when you are building alone in a casual way. But when two people are contributing, when both of you are working on different features simultaneously, you need branches.
I learned how to create a feature branch. How to commit changes to it. How to pull Arjun's commits into my local environment. How to handle merge scenarios when both of us had changed related parts of the code. How to review changes before they get merged into the main branch.
This is something that engineering colleges teach in theory. But working through it on a real, active project with a real collaborator, needing to make sure your changes do not break his work and vice versa, that teaches you what no lecture slide ever fully communicates.
ScholarDesk became a real world, industry standard development experience because of those weeks of collaborative work with Arjun.
🤖 Saathi: The AI Study Assistant
One of the features I was most excited to include was an AI chatbot for students.
I had already built a chatbot once before, during the development of another project, using the Google Gemini API. I knew the flow. You set up your API key, you structure the request, you handle the response, you display it in the UI.
What I did this time was take that experience and build something more specific. Saathi, the AI study assistant built into ScholarDesk, is designed to feel like a study companion for students. Not just a generic chatbot but something that can answer academic questions, help clarify concepts, and be genuinely useful during study sessions.
The name Saathi means companion in Hindi. And that is exactly the intention. A student sitting alone at 11 PM trying to understand a concept should feel like there is something in the app that is actually on their side.
🚀 Deployment: A Whole New World
When the web app was complete, there was one more chapter left. Deployment.
Putting a web app on your own laptop and running it with Flask's development server is one thing. The app is alive, but only on your machine. No one else can visit it. For ScholarDesk to actually matter, it needed to be on the internet.
I used PythonAnywhere, which is a cloud hosting platform designed specifically for Python web applications. But deployment is not just clicking a button. I had to set up the environment manually. Installing dependencies from requirements.txt on a remote server. Configuring the WSGI file so the server knows how to run the Flask application. Managing file paths that work differently on a server than on a local machine. Dealing with environment variables for sensitive data like API keys.
There were errors. Of course there were. But every error during deployment taught me something about how web servers actually work, how the gap between development and production is real and specific, and how the details matter in ways that your local environment forgives but a production server does not.
ScholarDesk is now live at scholardesk.pythonanywhere.com.
Type that into your browser and a real web application built by a first year engineering student from Sanjivani College of Engineering loads up. That still feels surreal to say.
👥 16 Users and What That Number Actually Means
After the app went live, I did something that I think every student developer should do with their projects.
I shared it with friends who are not in a technical field.
Not with my coding friends who would look at the code and evaluate the architecture. With people who just use apps. People who would interact with ScholarDesk the same way any real user would, without any technical bias, without any familiarity with how it was built.
I collected their feedback through a Google Form.
The reviews came back. People were using it. People were managing their notes in it. People found Saathi helpful. There were suggestions, there were things they wanted improved, but there was genuine usage.
And then I checked the user count.
16 users.
I want to be honest with you here. 16 is not a big number. On any scale of what an app's user base should look like, 16 is tiny. I am aware of that.
But let me tell you what 16 feels like when you built something from scratch during exam preparation, when the first version was a terminal program running on your laptop, when you did not know what SQLite queries looked like or how Flask routing worked or what a WSGI file was.
16 people chose to register on something you built. 16 people created accounts, logged in, and started using features you designed, features you debugged, features you thought about at 11 PM when everyone else was sleeping. 16 people found it useful enough to keep using.
That is not a number. That is proof. Proof that you built something real. Something that works. Something that matters to actual humans who have no obligation to be kind to you.
Reading those Google Form responses gave me a satisfaction that no exam score has ever quite replicated.
📚 What This Project Actually Taught Me
Let me lay this out clearly because I think there are students reading this who are on the edge of starting something similar and need to hear this part.
SQLite and databases taught me that data persistence is the foundation of everything. The moment data outlives the program that created it, software becomes real.
Flask routing taught me how the internet actually works at the level of requests and responses. Not theoretically. Actually. You define a route, a browser hits that route, your function runs, a response goes back. That is the entire web.
Working with Arjun on multiple branches taught me that collaborative development is its own skill. It is not just writing good code. It is writing code that another person can understand, review, and build on top of.
Deployment taught me that the gap between a working app and a live app is filled with specific, learnable knowledge about servers, configurations, and environments.
And building during exam preparation taught me that the best time to learn is when something inside you is genuinely motivated, regardless of what is happening outside.
 |
| Landing Page |
 |
| Dashboard |
🔭 What Comes Next
ScholarDesk is live. The exams are three days away. June 5th is coming fast.
But ScholarDesk is not finished. The feedback from those 16 users is a roadmap. There are features to improve, edge cases Arjun pointed out that still need attention, and a UI that can always be made cleaner.
More than that, ScholarDesk taught me what building a complete product feels like from start to finish. CLI to full stack. Local to deployed. Zero users to sixteen.
The next project will be better because of this one. The one after that will be better because of the next. That is how this works.
The fighter is still building. 💪
🔗 Also Read:
Five Months of Silence, Five Months of Growth: My Second Semester Story My First Hackathon: Bugs, Breakthroughs, and the Best Classroom I Never Expected
"The best projects are not the ones built in comfort. They are the ones built when something inside you simply refuses to stop."
Signing off,
Mayur B. Gund
FY B.Tech CSE | Sanjivani College of Engineering
Comments
Post a Comment