Last weekend my good friend and work colleague, Amy Peniston, and I wanted to see if we could build an entire thing in a weekend. We hit upon the idea for Grattr a simple web application that would allow you to publicly attach demographic information to your email address.

Anyone who has used Gravatar will be familiar with this idea of uploading one avatar and making it available for any websites once they have your e-mail address. We thought it could be useful to offer the same functionality for your demographic attributes (e.g. White, British, Male). The idea first came to me when, during the COVID epidemic, at a press conference Bermuda’s Minister of Health was asked a question about whether the outcomes were worse for black people. The minister, quite rightly in my view, responded by asking how did the reporter expect that information to have been collected.

We thought this is a common problem if you are hosting a conference or other event: you need to know the race or gender of participants. If you don’t ask, how will you ever establish if you are underserving one or more communities? The idea for grattr.org (short for globally recognised demographic attributes) was born.

Once we’d picked a name and confirmed the domain was available we had to work out what we were going to do. We wanted to get the whole thing built in a weekend, so as not distract from our main project, PeerWyse, so we had to use a technology stack we were familiar with. For our main project, I’ve taken the lead on technical decision making, and so we’ve used Python and MySQL. I was concerned about getting something up and running in a weekend using that tech stack even with Heroku doing most of the heavy lifting. Consequently,  we went with Amy’s preferred choice: React.

I’d never done any React before, I’d never heard of Firebase, and I didn’t even know netlify was a thing. However, Amy told me it would be easy, and since I trust her, I agreed to dive right into it. I am so glad we did. It was a delightful experience.

The first three hours were spent getting a signup page working and connected to a database, with hindsight I’m surprised it even took that long. We were able to use Firebase to control account creation. We didn’t want to have to build a complicated engine to support different email addresses for the same user, so most of the other options were going to be out. By the time we took a break so I could go for brunch with my partner (it was a Saturday after all) we had a fully working signup page and login page as well as connections to Sentry for logging and it was all working on our local machine. Since we were using Material UI, it was even pretty (on a laptop anyway).

Amy and I were playing golf in the afternoon, so we didn’t do much else together on Saturday though we came back together on Sunday to see if we could get this thing killed off in a weekend.

One of the practices that Amy and I have gotten into over the last six months has been alternating who is driving the computer between each pair programming session. We typically log into a slack call or WhatsApp for audio and then use VSCode to share a live coding session. Switching drivers improves the probability that whatever we are working on will work on both of our machines and lowers the friction to add that extra feature we’ve been thinking about when we have a spare moment. 

It’s an interesting question that I don’t know the answer to; if we were ever to go full-time working together, would I be willing to give up our current model of working? I’ve found it to be so productive. I also suspect we would never have found our current model of working without COVID, being able to work with someone else but without having to get out of one’s pyjamas is lovely. I’ve always been a big proponent of pair-programming. I appreciate an alternative perspective. Still, there’s an awkwardness to being so physically proximate to someone for such a long time which I just don’t seem to experience when it feels more like Amy is in my head seeing through my eyes (via headphones and a shared screen).

Sunday morning arrived, we brought a library in to provide a human-readable reference to when your attributes were last pushed to the database and started to write the attributes to the database.

A whirlygig followed so the page didn’t seem so slow to load and so we could differentiate between the time it took to log in and the time it took to load your attributes. 

We had to play around a bit to get the read and write permissions correct on Firebase. To reduce any issues with privacy, we wanted everything to be public readable so that we were more “hosting” information than “storing” it. Again with hindsight I’m kind of lost as to why this was so hard once we had it working it just worked.

We finished the day with everything working. We were using Firebase with a world-readable table; therefore, we even had a working API too. The project had been a great learning experience; we’d proven that we really could build nice things in a weekend (even leaving time for a round of golf and brunch with my partner).

I tried to show the app to my partner. It became apparent that working on a laptop meant that we hadn’t understood that having a signup pane on one side of the screen and login on the opposite side just wasn’t going to work on a phone in portrait mode. Out came Material UI’s Accordion and after a bit of fiddling around, we had something that displayed prettily on the phone too.

One of the really great things about working with Amy is she just has to make everything pretty. As a mathematician by training, I like to think that I can appreciate beauty. However, I am incapable of motivating myself into doing it (if for no other reason than I couldn’t even if I tried). Consequently, there was some editing of padding and CSS which made the page really “pop” including stylising one of the checkboxes from the Purple theme she’d chosen into a logo.

Having now both completed Y Combinator’s startup school we knew we had enough to launch, so we did, posting to Show HN so all the world could see and one guy from Denmark could give it a go. I think it would be fair to say it was not the most successful Show HN of all time.

All that was left to do by Wednesday morning was to get the required DNS entries set up so we could use AWS Route 53 to point to the lambda function we had written to parse out the JSON and return it on api.grattr.org. We were able to use the npm package serverless to make this easy.
All the source code for grattr.org is available from our GitHub repo if you’d like to see some additional options for attributes, please feel free to raise a Pull Request to add them. You can read about how to access our API on our website which is another beautiful creation of Amy Peniston.