This is the story by one of our engineers, Derrick, of how two new employees at a young startup built a useful mobile app on a plane ride across the Pacific. It’s also an argument: internal tools can start as spontaneous hacks that spring up from a need and from collaboration between employees in different parts of the organization.
In my third week of working at Branch, we made a last-minute decision to attend Mobile World Congress in Barcelona. We decided that my coworker Austin and I would go (as the newest additions to the team, we had the most flexible schedules). We bought two plane tickets, found an AirBnB with a couple twin beds in a historic town in Barcelona, and ordered some t-shirts. At under 15 employees, this was a big deal for us.
Austin and I started at Branch the same day. Austin works in sales and marketing, I work in engineering and customer support. We both are passionate about making developers’ lives easier.
I distinctly remember the day that we boarded our flight to Barcelona. We barely knew each other and had hardly talked outside of the last-minute planning we’d done to actualize the trip. As we took our seats, I marveled at our luck: we had more legroom than we anticipated. Austin immediately started talking about building apps…
Prior to joining Branch, I was one of the first users of Branch at my own company. Last year I built The League’s app from the ground up. Back in May, a friend introduced me to a Stanford Graduate School of Business student with an app idea. She wanted to launch a dating app that didn’t suck. I was a novice iOS developer looking to for an opportunity to build something that people would actually use. I also was in a healthy relationship that started from mutual friends and Facebook, and the idea of Tinder terrified me. The League is premised on finding matches based not just on the basis of a few pictures, but rather on the basis of shared friends, as well as shared life, education and work experiences. At The League, we used Branch as the catalyst for a wait list that is now well over 100,000 long.
…Fast-forward to when Austin and I sat down on the plane to Barcelona. He started talking about building an app for our company. This started out as a hypothetical app related to a very real need: following up with people we were about to meet at the Mobile World Congress conference. Austin, being on the sales side, was already thinking about the post-conference work: processing dozens of interactions and their accompanying business cards. He would have to manually enter the details of each card into Salesforce, while racking his brain for scant details about those dozens of conversations. Then days or weeks later he would follow up with them, hoping to start a conversation about how awesome our product is and the potential for partnership.
It sounded overwhelming and impersonal.
Finding a problem to solve
Wouldn’t it be nice, he said, if he could simply use an app to enter in basic contact details and immediately follow up with everyone in real time? Wouldn’t it be nice to have that interaction recorded, and easily exported into Salesforce? Wouldn’t it be nice to have a handful of templates with various styles of pitches about our company so that sending a follow-up email was effortless, and personalizing easy? No forgotten conversations, no cryptic scribbles on the back of business cards, no worries.
This hypothetical conversation immediately turned into excitement. Convinced we could build this on the plane, I opened my laptop before we even took off. The above wishlist turned into our “product spec”. Our primary goals were:
1. Capture details about who we interacted with for after the conference
2. Easily send or queue up a follow-up email after each interaction
3. Add and customize email templates on the go as the conference progressed
We both have iPhones, and I only had experience with iOS, so no decision about platform was needed. Because Apple’s core APIs provide easy-to-use functionality for sending emails, storing data, and creating interfaces, we didn’t even consider a mobile web app. It was time to build an iOS app.
The first version was incredibly crude. There was no Salesforce integration, no pulling templates from remote servers, and no bells or whistles. We didn’t have WiFi on our trans-Atlantic voyage, which limited us to code I was familiar with or could easily locate in the docs already on my computer. So we took shortcuts.
Shortcuts are sometimes your friend. I may sound like a broken record of Silicon Valley soundbites, but remember, “Do things that don’t scale.” (Tweet this)
When a user entered their contact details and we saved them for later, we didn’t need a remote server or even a SQL database (Core Data or the like). In fact, I hadn’t touched Apple’s on-phone database, Core Data, in six months when I started building the iOS app. So I did something that would make any decent iOS engineer cringe: I stored contact details in NSUserDefaults.
For those of you who aren’t as familiar with iOS, using NSUserDefaults as a primary data store is the equivalent of keeping cash in your back pocket without a wallet, and that back pocket having a gaping hole in it. Any 3rd-party SDKs you include in your app can access NSUserDefaults, or even wipe it completely. It’s meant for keeping unimportant user preferences and temporal data, like what screen a user was on when they closed the app. Few users care if an app forgets what screen they visited last — at worst it’s a slight inconvenience.
It’s this temporal, fragile data store that I used to store data on contacts. If I could describe that in a word, that word would be “unsafe”. Or “stupid”. Or “hack”. [1]
And we were fine. Remember, we still had business cards if all else failed. Coming up with a robust storage solution on that plane ride — when we really cared about sending emails and lightening our post-conference load — would have actually been far dumber.
Don’t optimize prematurely
Here’s a simplified version of how we saved contacts:
That’s the kind of code you write on a plane. That’s the kind of code that saves you several hours and a lot of headache when a conference is over.
—
Sending emails is also easy with iOS. I didn’t look for a fancy library to automatically send templates stored remotely. I didn’t integrate with any of the great email APIs, though we could have. I simply pulled up the native email sender, prepopulated with the email subject, body and TO field. We decided to make our company email addresses the default mailbox on our phones so we wouldn’t have to select a FROM email every time we sent a message. That was it.
Here’s a simplified version of the code for sending emails:
This is slightly simplified, but there wasn’t much more to it than that. For version 0.1, there doesn’t need to be.
Templates were themselves crude — they started out as plain text with substitutions for the other person’s name, a unique URL pointing to our website, and the “from” person’s name (Austin or Derrick). We later converted the templates to be HTML — after the conference.
If sending failed due to poor internet connectivity, we still persisted the person’s contact information via NSUserDefaults, and we still had a draft email saved for sending later.
In the interest of time, I’m omitting a third code sample: we also integrated Branch. We had custom URLs for tracking clicks, which required only three lines of code:
1. one line of code started the Branch service
2. one line handled Branch deep links users clicked on (unnecessary for this app because it’s only used internally, but hey, it’s one line)
3. one line created a unique URL for each person we met (this line is actually in the first code snippet above)
As an engineer, it would have been embarrassing if I wasn’t able to integrate Branch in a couple minutes. That said, shameless plug: Branch is so simple you can integrate on a plane without WiFi. (For what it’s worth, so are other great services like Mixpanel — if you have the quick-start guide open in a browser tab before your plane takes off.)
The app worked beautifully. People we met saw our emails during or immediately after the conference. There was no 2-3 week delay during which the initial energy of the conference dissipated. We built a CSV export feature and bulk uploaded everyone’s contact details to Salesforce.
The best part was that we saved a ton of mental energy. Using this app was like receiving gifts at a birthday party and stopping after every present to scribble a 30-second thank you note. Then you’re not feeling guilty for weeks later about that list of people you need to thank. Following up (or at least drafting messages) immediately felt great and was definitely a morale boost throughout the exhausting conference.
I guarantee your team has a more experienced iOS, Android, or web developer than me. You can do this too. You don’t need a trip to the Stanford D.School or IDEO to get your team’s creative juices flowing (though it doesn’t hurt).
Carve out time, ignore incoming email, and get out of the office. Relieve an engineer or three from the daily grind of building and maintaining your core product. Grab some boba. Watch an episode of Silicon Valley and embrace the silly irony of it all. Then start dreaming about a world in which you do less manual work. You’d be surprised by what you can build in a day.
Takeaways
1. Get salespeople, marketers and engineers in the same room (or anywhere where doors are impossible to open for ten hours). Ask questions like “What is the most repetitive thing that you do? Could it be automated, even partially? What is the biggest source of headaches for you personally?” Have the engineers do the listening.
2. Do things that don’t scale. Take shortcuts. A crude but functional prototype beats a robust product that doesn’t get built (Tweet this). Build version 0.1 with the intention of using it immediately. Write unsafe, ugly code. If the resulting app/tool is useful, you can refactor code; if it isn’t, you didn’t waste time.
3. Don’t reinvent the wheel. Crafting software tools today is a matter of assembling lego blocks. A single engineer using the right 3rd-party SDKs — lego blocks — can launch a company, so he or she can certainly build an internal tool.
If you’ve built something cooler, brag about it in the comments below!
Thank you, Austin, for helping me write this post. I’m excited for the next flight together. If you’re looking to grow your app, read about how to build virality into your apps. Teaser: it’s not how you think.
Notes:
[1] In fact, we decided to use Branch links to track which users clicked through from our email to our website. Branch links can store data in a way that’s hidden from the end user. So we also threw contact data into these links in case something tragic happened to the data stored in the fragile NSUserDefaults data store.
[2] This link was the link we included in the email we sent to contacts after the conference. Branch allows you to see clicks on your links, and since we generated a unique link for everyone, we knew who actually visited our website after reading our email. In reality, this Branch link contained much more data, like contact info and which template was used, so we could tell which templates performed the best.