April 10, 2020
Since I can remember I always dreamed about building an iPhone app and launching it on the App store. But I always just had one little problem...I didn’t know how to code! Over the years I’d always had ideas for apps and tried on a number of occasions to partner or pay developers to help me, but it never worked out.
So after my 3rd year of business school, when I came up with the idea for Focal, I said to myself - enough is enough. I’m just going to do this myself! How hard can it be?
I took a leave of absence from school and spent the next 8 months learning to code. I figure I spent about a 1000 hours learning and then another 1000 stumbling my way through building the Focal iPhone app.
I remember how proud I was when it got approved and launched on the App store! Even more so, when we booked our first photo shoot through it!
Unfortunately, after a couple months, we decided to shut the app down, but the idea for Focal persisted and we went on to build a website, which eventually evolved into the beautiful web app & SaaS application we have today.
It’s funny but anytime I tell this story, I always get the same question: How did you learn to code?
To which I normally ask: Why do you want to learn to code?
And the answers always remind me of myself all those years before because they are always so passionate about an idea of something they want to build - but they don’t know how. And I guess I am an example of someone that made it over the hurdle.
So this blog post is for all of you. The non-technical founders, who have amazing ideas and a fiery passion to create. I hope that by sharing some of my experience I can inspire and maybe guide some of you over the hurdle of learning to code.
I want to preface the following advice with the fact that by no means do I consider myself an experienced programmer or developer and nor should you. I can code, but my knowledge and skills are very narrow and utilitarian. I learned everything that I needed to know to build the first Focal iPhone app and nothing else. It means that I’m missing a lot of skills and experience that you would find in an actually proficient software developer. Like the ability to work in a team or write readable structured code.
You know those athletic people that are just really good at any sport they play? They have the worst technique imaginable, but they manage to pick it up and dominate the rest of the gym class? That’s me as a programmer. I can do it but it isn’t pretty. Put me next to a real athlete and I just look like a headless chicken :)
Well with that in mind here are my 8 lessons for learning to code as a non-technical founder:
A mistake I made very early on is that I wanted to start a company and not just build an app. If you’re in the same boat, I highly suggest not going down the rabbit hole of learning to code, then building something just to test out your idea. In my case, I spent nearly 2000 hours learning to code and building the Focal iPhone app, just to shut it down after a couple months. There are a lot simpler ways of validating your idea than learning to code! If you think you have a great idea for a startup venture - I suggest you exhaust yourself doing what’s called market validation and customer discovery. In short, you need to make sure what you build isn’t going to be useless. With the Focal iPhone app, we realized very early after launch that because people don’t book photo shoots that often, they don’t want the hassle of downloading an app. They would prefer a website that they can conveniently visit. You’re probably thinking: what an obvious mistake! But when you’re passionate and caught up in your idea for a venture, it’s very easy to get tunnel vision. Instead, what you need to do is validate that your idea is solving a real problem. Talk to 25 people minimum and ask them how much they would be willing to pay for you to solve that problem for them. Then, if you find out that people are willing to pay, you should go out and find the simplest way you can to actually get them to pay you for it. What I mean is that you don’t need to build an app or even a website. If it’s possible, offer to solve their problem manually. It’ll probably be a ton of work for you, but if you can even get 1 or 2 people to pay for your solution to your problem with your manual and ugly solution - it means that the problem you are trying to solve is worth tackling. A great example of this is how Airbnb got started. They started by offering airbeds to sleep on in their apartment because there was a big conference in town that sold out all of the hotels. All they did was put up a simple website saying they were offering an airbed in their apartment for $50 and to email them if you wanted to book it. And they had people book it! Boom, idea validated - then they started figuring out how to automate it and make it into a scalable product. Don’t jump the gun on this if you truly want to build a company.
I can’t emphasize enough how much it helped me that I had the goal of trying to build the Focal app. It gave me something to strive towards, and it was exciting thinking about the functionality and how it would have to work for a customer to actually book a photo shoot with it. Whatever it is that you want to build, find something tangible, that you want people to actually use and get value out of. That way you can work towards building something with a customer in mind! This is very important and I think really takes developers from pure programmers to product managers. It’s this ability to put yourself into the shoes of the user and think about how they are going to interact with what you’re creating. It’ll also be a huge motivator because you’ll have a goal of building something that you can ask people to play with and use! Trying to learn to code without an end in mind can easily become overwhelming. There’s so many things you could learn, but if you’re trying to build a particular thing, all you have to do is focus on building the features you need to make it work. You’ll always know what to work on next.
I started my coding journey in a Starbucks waiting to pick my girlfriend up from work. I was watching a youtube video series from: Let’s Build That App https://www.youtube.com/channel/UCuP2vJ6kRutQBfRmdcI92mA and I just decided to download Xcode and start following along. I had no idea what I was doing, but that was ok. I was literally copying line for line the code from this youtube video - but I was actually building something, and that was exciting! Getting that first facebook login page to work was so monumental in my coding journey because right off the bat I was able to see my app come together. Continually being able to see tangible progress gave me the confidence to keep going.
For the first couple weeks I would simply find youtube videos that corresponded to the part of my app that wanted to build. I started by building a facebook login page. Then I found a video on how to build a profile page and so on. A lot of coding has been done before so it isn’t necessary at all to figure out how to do it all from scratch. After all, almost every app needs a login page, a profile page etc.
By watching all these youtube videos and following along, I eventually started to learn by causality. By writing code, even though I didn’t understand it very well - I started to understand what it meant by what it was doing. So I started trying to make small modifications on the code that I learned in each youtube video. I started small. Trying to change the colour of something or move a button to a different location. Eventually through these small changes I started to be able to figure out how to build certain things on my own.
I’m not sure that this way of learning is for everyone. But it worked for me. I tried numerous times to watch “crash course” videos on code theory and fundamentals, but I found that the information was always far too overwhelming and I would get frustrated. This is just the way I learn. In university I would never read the textbooks. I would just start by doing the problems/exercises.
I’m sure you have this grand idea of the app that you want to build - complete with a plethora of features. My recommendation to you is to take that and throw it in the garbage! Instead, try to simplify your app down to the elementary benefit you want to provide the user. We’ll use the Airbnb example from #1. The main benefit they were providing to people was a place to stay in their apartment on an air mattress. And they fulfilled that need by posting a website up and offering the airbed in their apartment on it. Today the airbnb website and app have things like messaging, bookings etc. But they didn’t need that at the beginning. All they needed to validate was that someone was willing to sign up online to stay at their place on an airbed. Instead of trying to build a whole messaging system into that original website, they just used email - and it worked fine! So try not to get caught up on features that your app doesn’t absolutely need!
It’s critical that you do this because it’ll help guide you through your development process and ensure you focus on what’s most important. In my opinion, scope creep is the most dangerous force in software development.
When I built the first Focal app, I literally looked at what youtube videos were available to me and cobbled together the code. Meaning that if I couldn’t find a video on how to do X. I wouldn’t do it. This utilitarian approach allowed me to hyper-simplify my app. Instead of imagining all the amazing things that I wanted to build, I restricted my vision to the resources that I had available. It’s interesting because when I look back on this, it totally flipped the development process on its head. A lot of software starts out with the wireframes of your dreams and then the reality of building that hits and you begin to have to pare it down. What I did was the opposite, I searched through youtube and found what “wireframes” were available to me and I constructed my app around that. This prevented me from coming up with any outlandish layouts or features because I could only use such conventional code that people had bothered to make a youtube video about it!
As I learn more and more about software development, the more I realize that nobody really knows what they’re doing. Honestly, the majority of the time, developers haven’t done it before, so they just google best practices and go with that.
The good news for you as someone learning development is that there’s a ton of resources out there for almost anything that you’re doing. The bad news is there’s a lot of bad information out there as well. You’ll probably spend a lot of time copying code only to find out that it is not compatible with the latest version. Then you’ll have to figure out how to make it compatible.
If you're stuck on something or want to know how to build a particular feature. Just google it and you should be able to find some stack overflow threads and some sample code to try out!
At Focal, we recently had a 2nd year software engineering student ask us if she could volunteer for us to get experience. In hindsight, when I look back at the way I learned I think I probably could have benefitted exponentially by having someone experience to bounce questions off of. There were a lot of times that I got stuck on an elementary level problem just because I didn’t have any foundational experience in programming. Really silly things like not understanding classes, functions or the scope of variables (honestly still don’t know what some of these things are).
Learning to code doesn’t necessarily mean you have to get to a point where you can be productive and build things yourself. While this is a nice goal, the simple fact is that as a founder, there are a lot of other non-technical problems that will take up your time. So even if you become a top-notch developer, eventually you will need to let go of the reins to focus on building your company. At Focal, we now contract an in-house development team and I can’t emphasize enough how useful it is to have at least some development knowledge for the sole purpose of being able to effectively communicate with our dev team.
Being able to understand the development process enables you to think like the developers do and this is critical because as the founder, no one knows your product better than you. You’ll have an appreciation for the fact that in software development, you have to account for every little detail. Something I see often in non-technical founders is that they try and give developers the high level picture and then wind up frustrated when the product doesn’t come together the way they expected.
The more latitude you give the dev team to make their own product decisions, the higher chance that it won’t be what you want.
Having even minimal development experience will help you leaps and bounds over a non-technical founder in your ability to communicate effectively with your product/development team.
I hope that sharing my experience from trying to build the Focal iPhone app is somewhat insightful to someone out there - or at least somewhat entertaining to read. If you just finished reading this and have more questions feel free to contact me by clicking on the button be