My First Full-Stack Hackathon: Lessons from Building a Mobile App

Oarabile Koore - Oct 1 - - Dev Community

This post has been sitting in my drafts for months, gathering dust. Finally, I’m ready to let it see the light of day and share the experience of my first full-stack hackathon with you.


I will disclose that I am a self taught dev and this hackathon was the first time building a full-stack app.

The task of this hackathon was to build a mobile application for a housing corporation, and implement basic functions like sending house reports, house applications, viewing rental statements, querying for help and to view the FAQ's.

I was the android developer, and the other team mates went toe to toe battling with Xamarin for IOS and building the website portfolio for the project.

Btw, don't ask me why we did not use Xamarin for all the platforms, we are quiche eaters.

At the same time the competition rules did not take the fact that Apple binaries cannot be handed out without Big Brothers review.
So we planned to build an Android app and compile it to an IOS platform binary through Xamarin.

( ...one of my team-mates suggested this - I don't know what compilation magic is going on, i have built a language before and i know changing language bundles to another is not simple )

For android we used Javascript running on the DroidScript Framework, additionally the other team-mates battled with another hackathon and being at my request for feature implementations.

I chose DroidScript for its unique way of reducing ui complexity on android and its access to native api's while producing a small binary.

Furthermore I chose it basing on experience with ui development using it, I had ported the material design 3 library to DroidScript as a plugin recently therefore ui won't be an issue.

I decided not to add Node.js for the client application, because Node is way too heavy but for the admin app I used node with esm flavorings everywhere.

We completed the project in 4 days, and started drafting the admin app on the same day of submission but we didn't manage to complete it.

So, what was the result? Well, we didn’t win or even make it to the final round. In fact, we never received any feedback or updates, which was frustrating. I’m not disappointed by the loss but by the lack of transparency.


Despite everything, there were some valuable takeaways from this hackathon:

Write Tests, Even in a Hackathon
We skipped tests initially due to time constraints, but it came back to bite us. Testing would have helped us avoid making over 5000 Firebase calls during development. Lesson learned.

Don’t Underestimate XML DOM in Android
We struggled with UI performance, especially when adding multiple elements dynamically. The way Android’s XML DOM is handled by DroidScript turned out to be slower than expected. I should have used Enjine.IO, a web based version of DroidScript (written by core DroidScript Devs) but faster plus the benefits of being cross-platform.

Think Twice About Excluding Node.js
We thought excluding Node.js for the client app would save space, but it cost us functionality. Firebase was significantly slower when integrated as a script, compared to using it as a Node module. Next time, I’d reconsider the trade-offs.


Thank you for reading! This blog post may have taken months to finish, but the lessons I learned will last much longer.

You can check out the project here: Hackathon Project.

Let me know your thoughts!

. . .