Hangerang — How It’s Made: Part 1

Warning: This series of posts will be fairly nerdy. If you aren’t interested in app, web, or product development, read this instead. Actually read that article anyway if you don’t know what the heck Hangerang is, then come back here if you’re feeling sassy.


Hello code-folk, I’m sharing the ingredients and a bit of recipe that makes Hangerang tick. Why? Well why not. Professional chefs publish cooking recipes all the time. Even if you’re a novice at something, it’s fun to see how the meatballs are made. Also, this is my way of showing appreciation and giving credit to the actual geniuses who have created all these amazing components and libraries. Really, all I did was have an idea and combine some things in a particular way to get the intended result.

Let’s get cookin’!

In The Beginning…

Looking in my file system, I see that I created the logo for Hangerang on April 4th, 2016. It’s possible I had the idea stewing around for a while, but once I have an idea for something, I typically spend very little time coming up with a name and a logo. This part is very exciting for me. It’s like naming a band! It’s possible that the “App for Hangs” idea happened on that day. While brainstorming, I probably came up with a handful of other silly names, I recall settling on Hangerang because it was a play on the word “bangerang” coined in the Steven Spielberg movie Hook.

Rufio. Rufio. Roo-Fee-ooooooh!

The word Hangerang is fun to say, and might also evoke a concept of getting yourself out there socially and seeing the beneficial results come back. Well…maybe that’s a stretch. Likely, I thought a boomerang type logo would look really cool. Here’s the logo if you haven’t seen it before:

Shiny Happy Web Things Holding Hands: ReactJs & Firebase

I got started working in earnest on Hangerang in late December 2017. Previously, I came up with an interactive design concept using InVision and dabbled with React Native, but get stuck trying to get Facebook Authentication working in the manner that I needed. I then gave it a long, long “break”, casually researching various API frameworks and libraries, but always coming back to the idea that I wanted to use Firebase for my database/api needs.

Firebase was appealing to me for a few reasons:

  1. It is a realtime database
  2. It has an easy to understand JSON like data structure
  3. It is a Google product using Google servers, so uptime and scalability concerns are minimal
  4. It supports Javascript and Native Mobile app development
  5. It handles authentication and user management out of the box

As I said, I’d dabbled previously in React Native and tried my best to get familiar with React and functional programming by following along with various online courses but never getting a firm handle on anything. Learning by seeing has never really worked for me, I get bored and impatient after about 30 minutes. If you want to put be to sleep, put me in front of an online course, no matter how compelling the subject matter. Fortunately, after another search, I stumbled upon a simple tutorial that explained how to get Firebase and React working together in a concise enough manner that I could quickly get my hands dirty and embellish upon the core concepts:

Funnily enough, my local project folder is still named Fun Food Friends.

With this tutorial, I was able to set up a local React build, get it talking to Firebase, get user authentication running, set up a form, and save some data!

Why not build a Mobile App?

Initially, I intended to create an Native app, but as I thought about it more and more, I realized building Hangerang as a mobile app might be a mistake.

For starters, as I began to work with Firebase and define the data model, it occurred to me that I would probably not get it exactly right immediately out of the gate. As I iterated on the frontend and added features, so too would there be a need to iterate on the data structure. With web development, this iterative process is very quick and inexpensive. In the past I’ve found working in Xcode and Android Studio to be cumbersome by comparison.

Then, with every new app, there is the question of user adoption. With an app such as this, where it is necessary to have a robust user base, requiring a new user to download and install an app site-unseen is a pretty big ask and a huge barrier to adoption. With this particular app, it’s important for potential users to be able to view shared Hangs as quickly and seamlessly as possible. Every smartphone already has a built-in browser, and with the pairing of ReactJs and Firebase, the mobile web experience is close enough to a Native app.

Finally, once Hangerang is launched, I’ll be able to push fixes and changes very quickly. If it were a native app, this would not necessarily be the case.

If I’m lucky enough to gain widespread adoption, my guess is that I’ll have answered enough of the big questions and will have the resources to then build native versions of the app when the time comes.


That’s all for now. In the next episode, I’ll get into the UI and design of the Hangerang app. Please comment if you have any questions or feedback. Thanks for reading! Sign up for Hangerang news and updates here.