On 20th Jan 2023, I participated in my First Hackathon(HackFit2) which was hosted by Major League Hacking(MLH). In this post, I will be sharing my experience regarding the hackathon and I will also share some useful tips which I learned along the way. If you are a beginner(like me) you are going to learn a lot from this post, however, if you do have some experience with hackathons you can leave your valuable comments and learnings down below.
Table of Contents
Introduction to Hackathons π
Hackathon is basically an event hosted by some organization or institution, where individuals or groups participate and work on a project. The hackathon may have an “Agenda” or “Topic” however it is not necessary. Each hackathon has a schedule and some judgment criteria which are declared beforehand.
In my case, I participated in the MLH Hackathon HackFit2 which was a (2 Day/48-hour) remote hackathon. There were several mini-events and group talking events where we were simply chilling and playing. There was also a Synk Cybersecurity Challenge where we were supposed to find a TAG, I haven’t done it to date π¬. So, the topic for the Hackathon was Health and Fitness. Before you get your hopes up, let me tell you I didn’t win any prizes.

At the moment you are reading this post, I’m sure some Hackathons will be upcoming in MLH you can check that here(valid for 2023) if not check at DevPost.
Benefits of Hackathons π
- You get introduced to amazing people.
- Explore new tech stacks.
- Build an item for your portfolio.
- Documentation and Project Presentation Skills.
- Amazing Prizes and Swags.
- Sweet Naps XD
Getting Started π
I decided that I will be building an app for this hackathon, and as I am familiar with Flutter I used it to build the application.
IDEA: I wanted to build an App like Wikipedia where we can store information regarding different diseases. But like Wikipedia the data can be edited by everyone making it a collaborative platform and sort of Open Source. The disease symptoms, home remedies and related medications can be also provided in the disease detail.
MLH has several Sponsors for each Hackathon. In the event, I participated the Sponsors were Velo by Vix, Appwrite, Cohere, etc. For my project, I decided to use Appwrite as my backend as we had been provided with free access to Appwrite. The experience was similar to Firebase, however, I believe it is still in its initial stages. The setup for Appwrite was very similar to Firebase. However, the Firebase has a better interface and support I would say.
Finalizing the idea π€β
So the ideation and basic design took about 3-4 hours, after which I was sure about the idea and came up with the name Self-Remedy (Self-representing the Collaborative Nature). Next, I collected some data for the project as we wanted some pre-existing diseases in our app, otherwise, it would’ve been really hard to display the app to the judges. I saved the data in a .json
file and pushed it to the Appwrite server all at once(Ps: Adding them manually to Appwrite would’ve been a painful process). So now my data was ready, and I just had to use the API endpoints exposed by Appwrite to consume and manipulate the data.
Collecting Assets π¦π¦
In Flutter getting fonts is quite simplistic, simply use the google_fonts
package and you can access any fonts. However, I needed graphics, Illustrations, a Logo, and an App Design. Gathered whatever illustrations were around for a particular disease and edited them slightly and our image assets were also ready. For app design, I took references from many apps, took one component from one app another from another app merged it all together and I was good to get started with coding.


Coding ASAP π©βπ»
I started by creating a Flutter Project, adding assets, packages, and the logic for Appwrite. Creating the app was a hard task given the time period. Also, I wanted the app to be presentable so I had to take care of the design as well as functionality at the same time. Approximately, I had to code ~8 Pages and the Logic for consuming Appwrite APIs. After 2 days of sleepless nights, I created a presentable app and the UI was looking quite good, the functionality also worked as I expected it to.
I didn’t mention it earlier but we need to create a Video Demo showing and explaining your project. That was my next step as you can’t give a demo of your project till it is built to your satisfaction. Following you also need to create documentation of the project that we will discuss later.
Creating Video Demo πΉπ½
I started recording and explaining my app, the time limit was around 2 mins so I had to keep it brief. As you might think, a vertical phone video with a black background is not the best thing to submit. So I edited the video on Adobe Premiere Pro, I had used it earlier so I was familiar with it. Added some background color, and some text and the video was good to go. I posted it on Youtube and provided the Link in the project submission at DevPost.
At this point the initial submission was required, i.e we had to submit the project details and code, though we can edit them in another 2 hours. Let’s say the initial submission was at (3:30 PM) so we could still modify it till (5:30 PM). Here, 5:30 PM is the final Deadline.
If you are really reading along you might remember my documentation was still left, I knew I could edit it later. So I filled it with temporary values for now, which I would then modify later.
Documentation ππ
You can basically create your own documentation as you create in GitHub, however, they provide a template that is related to the judgment criteria. So it’s preferred that you fill the initial template provided, and add along necessary details if required. In my case, some of the sections in the initial template are:
- Inspiration
- What it does
- How you built it?
- Challenges, Accomplishment
- What you learned and What’s next
These are generally long-type answers, as you are supposed to explain your project here. I filled them up, along with the app description and app screenshots. I took special efforts to ensure that everything matched the theme. Like a brand, I ensured that the app experience, banner experience, and video experience should be similar. I have attached the screenshots below:


After submitting these, I finally submitted the project, and then I felt relieved. Not for long though as the results were to be announced after just two hours. Till then all the submissions video were displayed in a live stream (Ps: You can see my project at 18:10).
If you expect a heading with Rewards, I already told you I didn’t win ππ’. So instead we will be having a heading on Learnings and Improvements.
My Mistakes π
1. Unclear audio in the video π§
I worked hard on my Idea, App User Interface, Banners, Videos, etc just like everyone must have done. However, this was my first Hackathon and my first time recording audio. I already had experience in the rest of the things like Coding, Editing Images & Videos, and Documentation. Thus, I was not able to successfully communicate what the project ideation was. This was because of less time but also a lack of experience in vocabulary skills. It can be safe to say that my idea didn’t get through my video also I didn’t realize the audio was quite low and unclear.
- Ps: The video attached above was an improved audio version of the original submitted video.
Judges have a short amount of time to dedicate to each project, so you would do a favour to them and yourself if you explain everything in your video as simply as possible, as video is the first thing they will see in your project. Even if you are not able to display all of your functionalities the agenda should be clear by watching the video. That will decide if they are interested in your project and if they should read ahead about your project.
2. No Commit History π«
I worked for two days on my local system without making a commi
t. Just when the time for submission was near I created a GitHub Repository and pushed the code. This is a bad practice as the Judges need Commit History to ensure that you have been working on this project since the beginning and what features you added along the way. Otherwise, anyone may post their previous projects created over longer spans of time, which would be unfair.
TLDR;
- Check the website for all details regarding the demo video duration, deadlines, and mini-events.
- Start preparing the video 5-6 hours before Submission time. Ensure the video intentionally does not exceed the specified duration.
- The idea behind your project should be clear through your video.
- Do not reinvent the wheel, use the tools available as it’s a timed event.
- Ensure a good commit history.
- Winning is never the goal, learning in public is.
- Meet people, create a team and enjoy the event.
Resources π€«
- Your Devpost submissions suck
- Upcoming Hackathons
- Get Engaged in Open Source: KunalKushwaha
Conclusion π
The hackathon was a very fun learning experience, the coach and mentors were very helpful and kind. Always remember, one who can learn from failure is a winner for sure. Whether you win or not, the project gets added to your portfolio, you get well-versed with the tech stack you are using, and more than that you get guidance from senior developers. Promote Learning in Public because it acts as proof of work. Closing note, get engaged in hackathons, meet new people, explore new things and help other people.
Further, I would like you to check out my posts on Flutter-related topics if you’re interested.
- Testing in Flutter
- DraggableScrollableSheet In Flutter
- Null Safety in Dart, Flutter Essentials
- GetX in Flutter
- Streams in Flutter, Simplified
- App Lifecycle in Flutter