I just published an app. My own app. This is my entire, unedited journey through that process, which in my case took a whopping 3 years. Warning: Your results may vary.

Short version: buckle up, Billy.

For some context, I have a master's degree in Computer Science, and have been working in the software development industry for 20 years by this point. BUT I haven't coded professionally since the iPhone came out. Which kind of means I don't know anything. I moved on to project management, sales, management, and eventually starting my own business.

My app is a fitness app. Why, you ask? Does the world really need another one? Aren't there like a million of them, already?

Well, it started more as a personal experiment based on the question: what is the scientific optimal approach to fitness. None of the existing apps from Nike and others solve this. They offer you tons of exciting content, but make no effort to tell you specifically how to improve and get results. It's all marketing.

Fitness can't be art, so there must be a best solution. As I got deeper into this question, it started to make sense to model and experiment with potential solutions, so I started building an app.

So let me take you through the phases of any app. Depending on what you're doing, your experience may be much easier, or much harder than mine. But you wouldn't skip any.

Notice I use the word phase, rather than step, because each step is really a process of it's own. Not a thing you tick off the list and move on. In fact, most ideas get stuck in one of these phases, and die off. That certainly almost happened to me at almost EVERY phase.

Phase 0: Idea

The idea for my app actually goes way, way back 17 years. That's before iPhones, Facebook, or Machine Learning for you youngsters.

I was doing my mandatory military service in Finland, and as part of my training I had to go the gym. I was a real pencil neck, and had no idea what to do. Everyone I asked gave me different answers on what to do. To me, as a man of science, that seemed odd. Was there no right answer?

So I did some research. Turns out, there were as many answers as there were people giving them. Almost no consistency. Not in the advice, nor the terminology, and any scientific basis was thin at best. Everyone's solution was "the best". That doesn't add up. Everyone was selling something. Products like guide books and special gym gear. Services like coaching and seminars. Above all else, it was marketing. Not science.

What would Navy SEALS do?

So I thought to myself, who can I look to for example? What am I actually looking for? How would I know the right solution if I found it?

The first obvious answer was professional athletes. If you could run the 100 meters faster than anyone, surely you must have trained well. If you could lift 200 kilograms over your head, you probably had to do a lot of things right. For me though, that had two issues.

One, all professional athletes are specialists, whereas normal people are generalists. Usain Bolt would suck at both weightlifting and long distance running, because they don't align with his goal.

Two, they job is training. They train every day. Often multiple times a day. They train so hard, that all they have energy for is eating and sleeping. Normal people have other jobs, and other priorities, like kids.

So who needs a balance of strength, endurance, and power? Someone who not only needs to perform at peak levels, but sustain that through-out their life, not just at an event. Someone who has an actual job, that requires high levels of fitness, without that being the job itself.

Soldiers. But not ordinary soldiers like myself. Elite soldiers. Like Navy SEALs.

On the internet of old, I finally stumbled across a fitness manual written by the SEALs, for the SEALs. It was 300 pages of pure gold. It was rigorous. It was scientific. It told you what to do, and why. How much, how often. How to combine methods into programs. This, I could use.

Most importantly however, they quantified fitness. They baselined how many pushups a soldier should do, how much weight they should lift and how many times, how fast they should run over various distances. I could score myself against that baseline. I would know how bad I was, but crucially see how much I improved over time.

This wasn't marketing. This was finally science!

Excel magic

Given that this was the early 2000's, the most advanced technology available was Microsoft Excel. So I plugged in the models and algorithms from the SEALs manual, and created my own app. It calculated an optimal new workout each time, based on my previous results. Which I had to fiddle around with before and after each workout, and yeah, print. And carry to the gym, along with a pencil.

End of story? For many years, that was the best you could do. There was no real benefit of making a website of it, since you would still need to carry your laptop and charger to the gym. So pencil & paper it was.

Phase 1: Concept

So that was kind of what I did for 15 years. On and off, because spreadsheets, paper, pencil. Some years I didn't have time for the gym at all, because work and kids. So what happened?

Well, I moved to Singapore. Or rather, when you live in Singapore most families have a domestic helper that lives with you. Did she code the app then? No, it just meant that suddenly I had 3-4 hours of free time each night after the kids went to bed. No dishes, cleaning, groceries, or cooking.

So I went to the gym again, because in Singapore most condos have a gym of some sorts downstairs. So I pulled out my trusty spreadsheets again, which didn't convert well into Apple's Numbers, since people had moved on from Microsoft PC's over the years.

So I thought to myself, how hard could it be to just copy/paste these simple algorithms into an app? And, three years later, voila!

Ironically, I started my app with another spreadsheet. To kind of sketch out what it would do, and what kind of information would be shown on the various screens.

Phase 2: Prototype

This was also when the Apple Watch had just come out, so to me it felt natural to focus on iOS first. Running the app on the watch would be even better than a phone, because you wouldn't have to pull it out of your pocket all the time. Just a flick of the wrist. Apple had also released a new programming language called Swift, which was supposedly a lot easier to learn than the more hardcore Objective C language.

So I started coding. Not for you, or any imaginary customer. For myself. I wanted to create something that solved MY problem.

I found Apple's XCode, which is tool you use to write code, much more approachable than the tools I had used in my Enterprise Java days. Everything was included in the package, and you could get results right away. No fiddling around with various open-source packages and servers just to see a "Hello world" on the screen.

XCode came with a bunch of things that made it easy to experiment with quickly. You could create new screens in a visual "storyboard" where you could literally drag & drop buttons and images and stuff. There was a "simulator" that allowed you to run your program on different devices like iPhones and the new Apple Watch.

I found that if I plugged in my iPhone into my laptop, I could actually install whatever I had just coded right onto my phone, and walk into the gym!

It was awesome, and amazing. So I went a bit nuts.

Military efficiency

Given the military inspiration for the concept, I wanted to make something a Navy SEAL would use. Not because I thought they would, but because I thought it was super cool. Yes, I'm actually a man child.

That took my mind immediately into things like scores, points, and rank to represent how I stacked up against the big dogs. Poorly, as expected.

Go HUD, or go home

The more I learned about creating designs for apps, the deeper I went into the graphics capabilities Apple offers. Instead of dragging and dropping stuff, you could write algorithms to create your design instead. During college I paid for beers by doing a bit of web design, so this was appealing to me. So I went a bit nuts again.

What's cooler than military stuff? Space military stuff. I'm a huge sci-fi nerd, so I trawled the internet for cool heads-up-displays. Like the ones on fighter jets. Or space ships.

Yes, every line you see is generated programatically. You could even animate them based on data and user interactions. This was MY dream app. Not yours.

So I had a working app, and I liked it. Job done? More like job started.

Phase 3: Design

I was getting a little proud of my app, so I showed it to a bunch of people. They thought the idea was pretty cool, but everyone said the UI was great if you were me, not so great if you were, well normal.

This is when I first really thought about launching the app. If we just redid the designs, then perhaps other people could use it. I didn't think of it as a business or anything, but I loved the idea of having my own app on the App Store. Having worked in the industry for over a decade, everything was for someone else. This would be mine.

So I brought in more people. Rather than hire, because this wasn't really a business idea yet, I outsourced.

Designing for other people than me

In many ways, this was a complete restart. Rather than change the colors, we started fresh. So we started from fundamental questions.

What is the audience?

I wanted to solve the fitness problem for normal people. People with jobs and kids. People who don't have time to research obscure military manuals. People that want results, and want to see improvement to see they're on track. All of this with limited time spent.

Who are potential users? What are they like?

Professionals. Mid twenties to mid forties. Short on time. Some would be fit already. Some couch potatoes. They would have different fitness goals in mind. Some would have gym access, some wouldn't.

How do people currently go about solving this problem?

Right now, you have three general options. Pay $100 a session for a personal trainer, problem solved. Except most people can't afford one. Use existing fitness tracking apps, which give you no advice, and just track whatever you're doing. Or not doing. So most people just go to the gym and do random stuff that feels good, based on what a friend recommended 5-years ago after a few brewskis. Based on some viral marketing hocus-pocus, probably.

What pain points do they experience currently?

No time. No progress. No results. Pretty much nothing but pain across the board, if you think about it. People spend money on gym memberships, gym gear, and nutrition, and see temporary results. They get demotivated, because progress is too slow to see in the mirror. They get injured, when they push to see results.

How can we help by solving those pain points?

Our approach was to try and actually solve the problem of fitness. Rather than give them choice, we would limit choice. By limiting choice, we could control the outcome and track progress every week. Basically shut up and do what I say. Kind of like a personal trainer, except super cheap and always in your pocket.

Since we would cater to a wide audience, with different goals, and different equipment, we would have to understand the user first. To be able to recommend a specific program, we would have to measure their baseline fitness somehow. Within their program, we would recommend specific workouts each week, and track progress to keep users motivated. Easy peasy!

Since the key concept of the app was to structure everything around the user's chosen goal, or "mission", we called the app Missionready!

How might we do that with an app?

This is the biggest mental leap. You're translating high-level concepts into buttons and swipes. We started with screens. How many would we need? Not that many it turns out. The focus would be on the weekly schedule, and the workout screen itself. The algorithms should simplify the key concepts of missions, programs, workouts, scores, etc. within those screens. Other screens would fill the gaps of a complete app experience, like creating a profile, notifications, and settings.

What interactions do they need on those screens?

This was much harder. In some ways, we want to gather a lot of data about the user and their actions especially during workouts. Then again, we want to keep the experience simple, so there should always be a single clear action, rather than many confusing alternatives.

What about content?

This question gets overlooked in my experience. The structure of the content that is used or created within the app makes a big difference. In our case, it was to think about the relationship between goals, programs, workouts, and the trainer avatar that would give you advice. A LOT of my time was spent on further research into programs that could be adapted into mobile devices, require minimal special gear, make use of wearable devices, and produce time-efficient results backed by science.

What about algorithms?

Not all apps need algorithms. In fact, most fitness apps don't! They just track whatever you choose to do, and... nothing else. But we wanted to measure a baseline, recommend a personalized program, suggest specific workouts each week, configure each workout to your baseline, and measure your progress. Across whatever goals people had, and time-efficient programs. The answer is obvious. More spreadsheets. I must've spent hundreds of hours staring at that sucker.

All of the above is really user experience "UX", rather than design "UI". Designs you can change easily, but UX defines the whole app. Not easily changed. So it's important to get it right. From there we mapped out a user journey, which is a map of sorts of how the various screens and functionality come together to allow the user to achieve whatever outcome you are aiming for.

Don't skip this step, or you'll easily end up with a nice looking, but super confusing experience!

Many professional projects would have an additional step of producing detailed black & white sketches of each screen, a.k.a. wireframes, which are mainly used by developers to build the screens. In our case, the user journey was done on a detailed enough level to inform the developers on what went where.

Once we had the basic user journey mapped out, we went through several iterations of designs. To me, this was really important, since the goal was that other people would like it too. Design is highly subjective, so that's hard. You don't want to be generic enough to be boring, but you also don't want to design for a niche.

Not quite right

Even though the professional designers did most of the work, I had strong views on the layouts of some screens, especially the workout screen. You have to find a compromise between utility and simplicity.

Final, final. One more.

Once we had a working design (left) that we were satisfied with, I had issues moving on. "Good" didn't feel like it would be enough. The further you go in such a creative process, the more it means to you. In a way, it becomes you. So you start procrastinating over minutiae.

The final design is something I did myself, because it was hard to explain in words what exactly I wanted. I wanted to combine inspirational imagery, bright colors, but keep the interactive elements clearly separated. In a way, it borrows something from my original HUD design, while probably appealing to a wider audience. I hope.

Based on the final design, we produced a style guide which defines the colors, fonts, button styles, and other frequently used UI elements that developers can use to implement the final screens.

This process by itself took several months. Not because everyone was working on it full-time, but because we didn't. I had a day job, and the designers also had other projects. So it was slow. Still, it's never a matter of a few days. Getting the designs right takes time.

Phase 4: Build

There were a few big things I wanted to improve on the prototype app. I wanted to gather data and analytics, so we could figure out what people where doing, and how to make the app better.

First and foremost though, I wanted the app to be offline first. What does that mean? That you shouldn't require an internet connection to use the app. Why? Because a lot of gyms have really bad connectivity, and it kind of sucks if you can't use the app.

Having done some research, we settled to build around a few key technologies, namely Realm.io and Heroku. Realm provides an elegant and simple on-device database that you can use to build your models. Heroku is a cloud service, that allows you to build API's using a variety of popular backend frameworks such as Ruby.

We chose Google's Firebase for it's awesome user and event analytics, as well as integration with Crashlytics. Both have been a live-saver to figure out what's going on with users.

The plus and minus of Agile

For any app of even moderate complexity, it's hard to imagine how it would work before seeing it. It's an authentic chicken and egg problem. The only way around that is to start with some high-level features, say what the user would do in each screen of the user journey, and then kind of figure the rest out as you go.

We (mostly) used Asana for this purpose, which is great, because it allows you a ton of flexibility while being simple. Also, it's available on mobile, which is a lot more meaningful than you think. Ideas and questions will pop into your head in bed, in taxis, in the middle of a run. Having access to the backlog at all times makes a difference. I see you, JIRA!

So you start building the app a few features at a time, bottom up like. You test them, and use that experience to inform decisions about other features. And so on.

The downside with Agile, that inevitably you will run into huge gaps. You just hadn't thought about what you hadn't thought about. Mostly, that means compromise. Things you thought would be easy become really hard. So you drop them out. Trust me, it hurts. Every compromise feels like slashing a knife at your beautiful, original concept.

On best laid timelines

If there's one thing I've learned in my two decades in software development, it's that to make a good product, you need to be flexible on one of these things: time or money. Really, it's that simple. Good things don't happen fast or predictably. Creating an app is in someways an art form, not just engineering. People interact with the app to define their own personal experience. It's not easy to get it right the first time.

In our case, we had planned to launch in two months. Yeah, that didn't happen. It took, wait for it... 18 months.

The business end of things

While waiting for the app to be built, we started thinking more about how to commercialize this thing. This beast. Since we were clearly not just going to publish it and figure it out later, we might as well figure it out now.

Where would we find users? What would they actually pay for, if anything? How much would it cost to get users? How much would it cost to operate the platform? Would we need external funding at some point?

Of course, in many cases you would start with this. Find a problem to make you lots of money by solving it. But that was never my motivation. I started out to solve MY problem. Now, we wanted to solve that problem for others, too. And that might be expensive.

Phase 5: Beta

Even torture has to end at some point, and so towards the end of 2017 we had an app. It wasn't perfect, but it worked. Kind of. Again, channeling our inner Stoic, we decided to play the long game. Rather than push out a raw product, we would run a closed Beta. Luckily, again, Apple had us covered.

Getting your app out there

Like most things, Apple has thought of this very situation. You want some early feedback from users, to iron out the major kinks before launching. TestFlight is directly integrated into XCode, so you can push out new versions daily if you wanted.

From iTunes Connect, a kind of publishing tool for the App Store, you can manage versions of your app and users access to them. Adding new users is as simple as adding their email address. Apple automagically sends an invite to them, which allows them to download the app. Pretty amazing compared to the old days.

Managing feedback, fixes, and features

That began another process that didn't have a clear timeline. We wanted to get enough feedback, fix enough bugs, and add some new features to be confident in the product.

What could we do with all this data?

During the Beta, we also finally had data! A few hundred users had created thousands of data points over just a few weeks. So what? Well, now instead of our fixed algorithms, we could use machine learning to recommend programs and workouts based on your profile, predict recovery based on your heart-rate, sleep, and calories, and even estimate how many pushups you just did with your Apple Watch.

Luckily again, Apple had just recently come out with iOS11 and a new SDK called CoreML for Machine Learning. The benefit here is that you could now create Machine Learning models in leading open-source frameworks like scikit-learn, and literally drag & drop those models into XCode and call them as classes in your app. A very Apple-like solution! Above is an output of testing various scikit-learn classifiers as a basis for our profile recommendation algorithm.

This ultimately became the defining vision of the app. There is a virtuous cycle of gathering data, creating more specific recommendations on that data, and gathering more specific new data that is specific to apps and wearables. Missionready would be the start of something, not an end.

Phase 6: Launch

So here we are then. If you survived reading all this, you can appreciate the effort in not just writing it, but actually surviving the experience. Of course, many apps aren't this complicated. Many launch apps that are raw, and refine them in the hands of real users.

This is me pressing the "release" button after 3 years of working on this app. A good feeling. Hands trembling as sign of courage.

So now what?

Well, depending on what your plan is, you're either done, or just beginning. If your app has no backend or analytics, you won't have any clue what users are doing.

In our case, we've wired this sucker up like your neighbors house on Christmas Eve. The whole plan is to focus on gathering data on users, their behaviors, our algorithms, conversion funnels, and drop-off points. To let the data inform us what direction to take.

We'll also be tracking key metrics like retention, cost of acquisition, and lifetime value to justify further outside investment after a few months of solid data.

Want to try it?

So if fitness is something of a problem for you too, try the app. Feedback is more than welcomed.

HERE: Missionready for iOS

Skills I had to have, learn, or outsource:

Sketching of app ideas
Mockups of screens
Writing logic and algorithms
Writing requirements in the form of user-stories
Rapid prototyping to validate key concepts
Design, both UX and UI
Writing the actual app code
Extending your app with 3rd party frameworks
Testing the app on the simulator
Writing database + backend + API code
Testing the app and backend together
Managing code repositories incl. features, builds and releases
Project management to plan and track a timeline of above
Publishing on the App Store(s)
Machine Learning to make recommendations and predictions about data
Practical data science like exploration and cleaning of data
Patience

Tools that made it possible:

Google Docs for real-time collaboration on spreadsheets, slides, and docs
Asana task management for backlog, feedback, documentation, and todo's
Slack for communicating with different people/teams on different topics
Gimp as poor man's (open-source) Photoshop
XCode + Swift for the actual app development
Cocoapods for not reinventing the wheel through 3rd party libraries
Heroku + Ruby for (relatively) easy development of backend API's
Firebase + Crashlytics + BigQuery as the Google trinity of figuring what's wrong with your app
iTunes Connect + TestFlight to get your app in the hands of users
Python + scikit-learn + CoreML for Machine Learning for iOS apps
Atom as an awesome open-source editor for Ruby, Python, etc..
Squarespace + Mailchimp for super simple marketing of your app

NOTE: You can get started with pretty much all of the above for FREE, and only pay when you need premium capacity/tools for production usage. Only exception being Apple's Developer program, which is $100 per year once you want to distribute your app to other users besides yourself.

So... should you?

The real question is, can you? Not as in do you have the skills, but do you have what it takes to acquire them? I had almost none of the skills required when starting this project, but I had some relevant experience and the time and will to learn. Patience and determination were forced on me later.

If you find reading this article particularly exhilarating and inspiring, I would recommend it. If you're on the fence, start easy. Don't start by reading a book, jump right into it. Start by downloading XCode and trying the Swift Tour by Apple.

What's your app going to be, then?

I just published my first app! Here’s what it takes.