Building an App for Yourself — A Case Study of Heed
The ups, downs, late nights, year-long hiatuses, caffeine overdoses, and daily struggles working with the most meticulously demanding client of all — yourself.
They say the key to freelancing is maintaining a routine. They say to learn to say “no”. They say to know when to stop. They say to stick to your strengths. They say not to do too much at once. They say fail fast. Most of the time, I say they’re right. But sometimes, you have to throw what they say out the window.
The birth of an idea
I’ve calculated that I’ve roughly built over 100 iOS apps since I started in 2008. Some are currently available, some have faded away, some have since changed hands, some never made it to the App Store… and some I’m not even at liberty to talk about. Save for perhaps a dozen or so, all of those apps were built for a client or built as part of a larger team — the ideas behind them were not often my own in origin.
A noticeable pattern emerged through their lifespans: the ideas that originated directly as a solution to a problem often led to apps that lived longer, had better rates of success, and saw more recognition. I don’t think this is a surprising thing, but I do think it’s easy to lose sight of this —
Products should solve problems.
The problem
I have always been bad at email. I’m often too busy (read: lazy) to reply to emails I know I should reply to, I have no semblance of inbox organization, I try to mentally remember when I need to write someone back, and to top it off, I’m slightly OCD about getting rid of that little red icon badge, so I immediately mark every message as read. Needless to say, emailing me is a hit-or-miss endeavor. I prefer to think that email is bad at me.
Email has become noisy — a burden unto itself, an additional task no one needs. Too often the fix is either hyper-aggressive organization or neglect. It’s become difficult to heed the important stuff.
And yet the thought never occurred to me to build something better. I would try a new mail client, I would try a new method of archiving or starring messages — it never seemed to fix anything.
I finally hit a point where I knew I needed to solve my problem — I never thought to myself that I would make a product, I thought to myself I need a solution.
Turbine
Over a year ago, during the holiday break (which, as a freelancer, is much less a “break” and more an “observation”) I decided I would create an email app. I knew it needed to do several things to stand a chance at addressing my issues:
- Allow me to quickly and easily triage messages based on priority
- Decouple the concepts of “unread” and “important”
- Remove, or at the very least hide unnecessary and legacy email constructs
- Look good, if it wasn’t too much to ask
I had never worked with email before, I had no knowledge of how IMAP or SMTP servers worked or what the structure of an email object looked like… I had no idea where to even start. So I started at the beginning.
I began designing, I settled on the name, I decided it would be targeted for the iPad to start (more on that decision later), I did research into how to integrate with email servers — the app quickly began to take shape.
When all was said and done, I built Turbine for iPad over the course of two months, here and there in between more-pressing client work. I created a splash page for the app, I did a small amount of beta testing, I submitted to Apple and got approved for sale, a price for which I had decided on $2.99.
Turbine is dead, long live Turbine
Despite being approved for sale, Turbine never saw the App Store.
Why, what happened? Did it fail? It failed me.
Turbine had some fundamental issues. Some were performance based, some were reliability based — but the significant one was that it wasn’t a good enough solution for my initial problem. I was not comfortable putting something out there that offered a solution that I wasn’t even satisfied with. The short list:
- Turbine should have been iPhone first. The email-client form factor of an OSX app was too stuck in my head, and I ended up targeting iPad because of its more-similar form factor — ignoring the fact that my own use case screamed for it to be iPhone.
- Turbine lost sight of its primary goals, and along the way I found myself backing in legacy email constructs that I had sworn to remove and burying / complicating the core functionality I wanted in the first place — perhaps due to it creepingly becoming more of a product and less a solution.
- Technically, it was not as performant as it needed to be, especially if I had aspirations of it becoming my default email client.
And so the project died.
Was it a hard decision? Yes and no — yes because of the time and effort I had put into it, but no because I knew it wasn’t good enough. In a weird way I was proud to deem it unsatisfactory.
Pride should be stronger than the excitement of an idea or the fear of its failure.
Round Two: This time it’s personal
Having spent more time on Turbine than I had ever planned to, or could even have afforded to, I washed my hands clean of the project and abandoned it wholesale. I got the occasional inquiry from time to time about its status — none of which roused my interest in the project in the least.
I still had my email problem, though.
Then the holidays came around again — a full year after the project originally began. I’m not sure what it is about the holidays that seems to motivate me, maybe it’s staring another year in the eye, thinking about all that has and hasn’t been accomplished. Whatever the cause, I got the itch to solve my problem again.
And I decided to restart at the beginning. I learned a lot from my work on Turbine, but I had no interest in resurrecting it — I wanted to start from a clean slate, to do it right by me.
Armed with the motivation to build, another year’s worth of experience, and an existing workload with very little room to spare, I hit the pavement and hit it hard. I redesigned, I rebranded, I renamed. I built stronger code that I knew would scale better than before. I targeted the iPhone. I was decisive in my design decisions and took the time to turn corners rather than cut them. I refused to ignore the demanding client in me.
And to accomplish this, I had to throw what they say to do out the window. I wanted to build this app but, by all reasonable measures, I did not have the bandwidth for it. Sometimes you have to sacrifice. Sometimes you have to do “whatcha gotta do”. I strung together way too many 4AM nights, pounded way too much coffee, and imposed way too much mental stress on myself. Was it healthy? Absolutely not — I don’t recommend it. But I do recommend making time for your passions. How will you ever have time if you don’t make time? Routines and schedules and knowing when to say no are all fine and good. But sometimes, you just have to rock.
Introducing Heed
From concept to submission to the App Store, I built Heed in just over 3 weeks. It was very much a study in hustle.
I knew that whatever window I had to work on it was a narrow one and closing fast.
Heed does exactly what I had set out to build it to do over a year ago:
- Quickly triage messages that needed my action by swiping the message rows.
- Double tap a message to mark it as read — and get rid of that red icon badge even sooner.
- Remove the unused vestiges of typical email clients.
- Be good looking.
Additionally, Heed gained a couple “no brainer” features that pointed themselves out during use testing:
- Create rules that automatically set new messages to a given priority if they match certain sender or subject criteria. Autotriage. Nice.
- Easily mute or solo an email account to focus on seeing only what you want.
As a solution to my email problem, though, is where Heed really succeeds. I no longer neglect emails (except for the ones I intentionally neglect), I don’t spend any additional time dealing with email (organizing, sorting, traversing, hunting, etc), and the app is clean and snappy enough that I actually enjoy using it several times a day.
And perhaps most telling of all, from the time Heed was a bare-bones, minimally-functioning beta app, it has been my goto daily email client.
Heed is available for free in the iOS App Store
What now?
Killing a project for a year for the sole reason of being unsatisfied with it is a hell of a test in resolve. A test which I think has impactfully benefited not only the reborn project itself, but me as well. It’s made me aware of my standards and made me aware of my willingness to adhere to them. Sometimes when doing client work I think it’s too easy — arguably necessary, at times — to lose sight of this. When you have to answer to yourself, it’s not as easy.
Heed wouldn’t be what it is without Turbine, both literally and metaphorically. I learned a lot technically with Turbine that directly lent to a faster dev-cycle with Heed, but I learned a lot more from being wrong with Turbine. Heed is only right because of how and why Turbine was wrong.
It’s ok to be wrong, but it’s helpful to know when you are.
It’ll be fun to see what happens with Heed. Hopefully some people find it useful for their situation. As a product — as “just another email app” — I was never really concerned, though. I wasn’t building it so it could be a product. I know very well that Heed won’t be right for everyone; it may or may not solve your problem. But it’s right for me — it solves mine.
And after all, that’s why I built it… twice.
Read more about Heed at www.heedapp.com or download the app for free in the App Store.
I’m Keiran Flanigan and I build apps. If you enjoyed this article, leave a note and/or Recommend and Tweet it!
