I created something the world already has many solutions for; managing your task lists. I know what your thinking… “just what the world needs, another to-do app”. I was honestly resistant to creating a to-do app for that reason alone, but you know what? I needed to get shit done and those other apps weren’t helping.
I didn’t create Flee to get rich. I didn’t even create Flee with the mindset of growing it into a reliable source of income. But, it is a solution to a problem and I couldn’t have been the only person who needed something like it. I was right. Within a few weeks, my total financial investment was covered. I identified a problem, found a solution, got it built, and I didn’t lose money creating it. Mission accomplished.
Flee is for Mac and it’s available to download on the Mac App Store. It appears when scrolling from the top of your screen. It’s refreshingly simple to use and its drag and drop interface allows you to get things done the way you want.
The idea came from how I was managing my tasks on paper. At the beginning of the week I would take a piece of paper and fold it in half; labeling Monday to Friday on one side and leaving the other side open to whatever categories I chose during the week. Eventually, I came to realize this format would be useful on screen too.
Here is the weekly planner as a free printable download:
How Flee was created
Since the folded paper acted as a working prototype of sorts, it required few design elements to be successful for its purpose and the way I used it. Because of this, creating the visual design in Photoshop was relatively simple to do and being a designer, I was able to work immediately. The first visual design took only a few hours with the majority of time spent making the grid and spacing for typography just right.
This first step was crucial. To me, it is what would validate my idea. Can something I typically do on paper every day be replaced by an app? Over the next few days I opened and closed the design again, and again debating its fate… something I’ve commonly done in the past with other projects. As you already know, I decided to push further.
Next I had to design all the necessary components and finishing touches, which took some time. Flee was my side project, left for evenings without plans. There wasn’t a strict schedule I was adhering to and I didn’t alter my daily routine to make it work. My day started as it typically would with coffee and reading before jumping into a full-time commitment to my startup, NUVI – something that populated the majority of my task lists back then. I worked on the Flee design over the next few weeks totaling just under 20 hours. This included iconography, mouse events, transitions, and the about/preference windows. It was now ready for asset preparation and deliverables for a developer. That’s right, I wasn’t going to learn to code the app myself.
It’s often assumed that all a developer needs are some photoshop files and a quick explanation for them to get going on your project. My advice is to do everything possible to make your developer feel comfortable with the project and requirements. You know you’ve prepared things well for them when they come back with only a few questions. Too many questions mean you didn’t provide enough for them to understand the scope. No questions mean they are likely going to go off assumptions or truly do believe everyone is on the same page. Do not leave any rocks unturned.
I have been fortunate enough to work with developers of all types, so I already had an idea of what needs may come up during this build. For Flee, it was:
1. A click-through prototype showing every interaction: For this I used InVision. It’s was perfect for showing the app flow with annotations. It also served as the primary place of discussion throughout the project.
2. Animation showing how every transition and interaction should feel and appear: You don’t need to be some motion design expert to tackle this. I’m certainly not one. I used Keynote… take a moment to let that sink in. I took something the suits use for presentations and instead used it for prototyping a mac app walkthrough and it was quick and surprisingly simple. I recommend reading “How To Prototype UI Animations in Keynote” on Smashing Magazine if you’re interested animating this way.
3. 72PPI and Retina ready assets: If you have any graphical elements in your app, do your best to have them code ready for your developer. Expecting your developer to crop, export, and display every graphical element the way you envision is rarely successful in my experience. Be kind and save your developer from opening the complexity of Photoshop.
These 3 things were essential. Having them prepared and ready for a developers eyes added a level of security and confidence. It’s the first time you view everything under the microscope and put yourself in the shoes of someone else viewing your work. Once I was comfortable with everything I’ve prepared, I began the search for a developer.
(It’s worth noting that Flee is a simple app and more complex apps may benefit from getting a developer involved as soon as your idea forms.)
Finding a Developer
It is possible to build an app on a smaller budget. My goal was to build Flee under $1k, which I was successful at. This amount was rather arbitrary to me. I knew some developers would offer to build it for much less, just as I knew developers that would request five times that. Though, I had a side agenda. I wanted to see how much financial risk I could remove building an app. $1k seemed comfortable to me. If the build was unfavorable, I wouldn’t lose too much sleep over the loss. If the build turned out to be successful, I still might lose sleep, but that’s because the new found feasibility of building more products.
I put my Rolodex to the side and instead listed my project on Upwork, formally ODesk. It was my first time using a service like it and I couldn’t be happier with the experience. Through Upwork, I was able to list my project and see if any developers had interest. Within a few days, I received messages from four different developers. Two of them actually read my job description, the others did not. You have to be careful and precise in your wording. There will be trigger happy developers placing bids on every project and others that are much more selective to the type of projects they work on. Luckily, out of the four who reached out, I was genuinely excited to work with one of them. I liked his responses and interest in what I was trying to build. He asked very good questions that I wasn’t expecting – things about usability and experience. We worked together to estimate how much time the build might take and ended up with an estimation of around 40 hours. He also preferred the job to be done as a fixed price where he gets paid at the end. Fine by me. Interestingly, he felt it would motivate him more than an hourly rate.
Working together was painless. Once the first prototype was created and working we both tested it out for a few days. I came back with some notes and he offered insights from his perspective. The process for building apps often become iterative. You need to be open to feedback from others. If you alone flawlessly plan a product, it’s unlikely you are human. We swiftly worked through our concerns and continued to build. A few rounds later, Flee was officially labeled Version 1.0. It worked exactly as I hoped and better yet, it solved my productivity problem. I tested it for weeks before finally releasing it to the Mac App Store.
My work is sometimes constant experiments. Nowadays it’s advised to build hype around a product before releasing it. It’s advised to have an advertising plan, a website, and social media presence. I know those work, Flee is not my first product release. After writing a product description and strategically putting together screenshots, I decided I would simply put it on the app store and see what happens. While it was in the Apple submission queue, I purchased getflee.com and displayed the Flee logo along with a support email in case anyone coming from the Mac App Store had questions.
A few months have passed, and Flee is profitable. I’m getting emails from people saying they love Flee and that they’ve ditched other apps in favor of it. If Flee is helping people, and it is something they want, maybe I actually can turn it into a reliable source of income. Time will tell.
Flee now has a new website and soon I’ll begin to work in a marketing plan as well. For now, I’m taking it easy and learning from each tweak and day that passes. It’s a new year and this is just the beginning for Flee.
If anything, I hope this shows you that it is possible to tackle your own ideas on a schedule that works for you and start building side-income. Happy creating.