For a lot of non-technical founders setting out to build their product, it can be hard to understand just how much work needs to be done before you write a single line of code! In this post, I will break down much of the ground work that needs to be done by your tech team before you start to actually build out your product.
This initial setup involves getting the following ready:
- Setting up your accounts with the app stores you plan to launch in
- Setting up your cloud hosting and database hosting plans
- Setting up your domain and configuring your SSL certificates
- Setting up your code repository
- Setting up an alpha/beta testing process for pre-release testing
- Setting up your task and bug tracking system
- Choosing the framework(s) you plan to leverage to build out your technology
While all of these steps are fairly straightforward, and common to just about every development project, they are nonetheless absolutely critical, and in some cases the decisions you make here can affect your company in the future — sometimes even very far into the future!
So let’s take a look at them one by one…
Setting up your app store accounts
First, you need to get set up with the app stores. Luckily, this process has become much simpler in the last few years than it was in the beginning! But it does still require some time, so plan accordingly!
Getting started on Google Play is a piece of cake, as Google is well-known for minimizing the hoops you have to jump through. For the most part you just need to sign up and pay the annual developer fee and you are good to go.
Apple, on the other hand, requires a D&B number and some more detailed information about your business (or yourself, if you are signing up as an individual). While the D&B number is not hard to get, it can take a little while to get, so be prepared to wait a while.
After the initial business set up, there is actually quite a bit of technical set up required at this stage — notably, you need to generate some signing certificates and distribution profiles with Apple in order to build, sign and deploy you apps. You need even more certificates if you plan to send push notifications to users, or leverage some of the other specialized functions that the iOS SDK exposes to you.
On Google Play, similarly, you will need to generate some certificates for app signing, sending notifications, and a few other optional bits of functionality.
Again, none of these steps are particularly difficult, but they do take time, and it is highly advisable that you have your developer or someone else experienced in these setup steps get this stuff done for you, to prevent unnecessary delays.
Setting up your cloud and database hosting
Back in the old days, you could run a tech company from your bedroom if you had the technical know-how. These days, you still can — but if you plan to scale up in the future and potentially accomodate millions of users, you will want to plan ahead and make sure you are running your tech on a scalable platform.
But it’s not just scaling you have to think about — its also cost of maintanence!
Back in the day, when I was running Glowfoto, our technology was powered by several cabinets in a vibrant datacenter in downtown Los Angeles, which was host to a couple dozen servers all performing individual tasks (serving files, serving web pages, answering database requests, managing payments….)
While this worked great, it was on us to make sure these servers were running. If we started to outgrow our infrastructure, it was on us to bring in more servers, and reconfigure our software and hardware set up to handle the new load.
Often this meant spending hours — sometimes in the middle of the night — in a cold data center with a laptop and screwdriver getting everything configured.
But that’s not all! The new load would also come with new bandwidth requirements, which meant once we got everything ready for scale, we had to go down a few floors and negotiate a bandwidth and colocation upgrade!
Luckily we don’t deal with this stuff anymore. Services like Amazon AWS, Google Cloud Platform, and Microsoft’s Azure provide us with an almost set-it-and-forget-it place to host our technology. Ok, I’m exaggerating the degree to which this is “hands off”, but compared to the old days, hosting our tech in the cloud is a dream.
We also have a few higher level options if we want to give up a little control in return for a more managed platform (services like Heroku for example).
But in general, we just need to decide on a hosting platform, and ideally a managed database platform.
On the majority of the projects I work on these days, this means signing up with Amazon AWS for server hosting, and MongoDB for database hosting. And our Mongo instances are actually hosted and run on AWS hardware!
This setup not only involves signing up and configuring billing, but also making some initial technical decisions. Managing hosted platforms like AWS is full time job in itself these days, so definitely make sure someone experienced is setting this up for you!
Setting up your domain and configuring your SSL certificates
Modern mobile platforms no longer allow connections over old-school http — you now must connect to your API over https which means you need a certificate for your domain. Which, in turn, means you need a domain!
On AWS this entails setting up a load balancer in front of your EC2 instances, configuring a certificate to use for SSL and setting up your domain to use an alias on top of your http endpoint to allow for secure communication with your API.
Does that all sound like gibberish? Don’t worry, it’s actually pretty straightforward. But I would like to pause for a moment to point out that we are only half way through the setup phase, and we’ve already touched FIVE Amazon AWS services (six if you count the billing module)!
So far we’ve dealt with IAM, S3, EC2 or ElasticBeanstalk, Route 53, and Certificate Manager — and we haven’t even written a single line of code!
I have worked with very large companies that have actually had a single person in charge of one of those services — e.g. a non-programmer, devops employee who only deals with managing DNS via Route 53. Granted, that’s pretty rare, but what isn’t rare is having a single person in charge of the AWS services as a whole. Again, this is not a programmer, this is just an administrator in charge of AWS management.
Remember at this point, you likely have one person in charge of AWS, and everything else, including your code! Hopefully you can start to see how important this is.
Setting up your code repository
This is pretty straightforward, but we’re going to want a place to host our code!
Why do we want this? Well, if we bring on additional programmers later — either because the code becomes more complex, or we start to move to more parallel development (e.g. having one programmer work on Android, one programmer work on iOS, etc) — then we want an easy place for new coders to quickly grab the code and start digging in, and also a place where the team can be immediately aware when one programmer makes a change, so we all can stay in sync.
More importantly, in the early stages, its important that you have access to your code, so that if anything ever happens to your developer, you won’t have to wonder where your project is!
There are a few options here, but the most common is to sign up with Github and create a repository there. Again, this is a fairly technical step (at least at the signup stage) so you will definitely want your developer to do this for you.
Setting up a deployment system for alpha/beta testing
You may be aware of Apple’s Test Flight system for beta testing, and you may know that deploying apps on Android devices outside of the store is (relatively!) simple.
However, Test Flight requires apps to be approved by Apple’s testers, and sideloading Android apps still requires a few steps that confuses the average user.
On my projects, I use the Beta deployment system by Fabric, which allows me to fire off dozens of updates a day and keep my clients up to date as often as I want. This comes in especially handy when developing functionality that requires extra discussion — we can review multiple app updates in a single day and try out options right on our devices, rather than imagining what they will look like, or waiting for Apple to approve the latest iteration for Test Flight deployment.
Fabric Beta is an absolutely mandatory tool in our tool belt, it’s free, and it’s fairly user friendly. But there is a bit of setup involved in terms of getting signing certificates set up and inviting testers, so again you’ll want your developer to get this ready for you!
Setting up your task management and bug tracking
This is the one step that admittedly isn’t SUPER important, since in the early stages of most development projects, the team is fairly small and email and Skype/Slack etc will work just fine. But services like Asana are free and easy and its not a bad idea to start learning how to use them now, since soon enough they will be necessary!
Choosing your frameworks
This is where your choice of developer starts to really matter, and its the point just before we start to write that mythical first line of code.
Are we going to build our technology on top of a framework? And if so, which one?
There are a couple reasons to work with a framework, but the two most important are: they help keep your code readable and manageable if and when you bring on new developers, and they reduce the amount of code you have to write!
There are a few popular options you can use to build a mobile app on top of — two of them are Firebase and Parse. Both give you a common paradigm with which you can build out your system, and both give you some tools you can use to start to visualize your database, add data to your system, and monitor and administrate your system once it goes live.
But most important is what you can get out-of-the-box. Taking Parse, for example, you will get — right away on installation — the following:
- Simple push notification functionality on both platforms
- Basic email-verification for new users
- A robust user-authentication (signup, login, logout) system day one.
- A file upload and hosting framework for handling, for example, user images or uploads
- A well-defined framework for handling data validation (when and by whom objects can be created, deleted, or edited) and security (read/write access, security role definition, etc).
And more. These are all things you will need at some point and, without a framework like Parse providing them out of the box, will need to be coded by your developer. Leveraging Parse will allow you to cut literally hundreds of hours off of your development over the lifespan of your app by simple using this framework and the common systems it includes.
Obviously your developer will need to know how to use the framework you choose, but more importantly your developer should have the expertise to help you choose which framework is right for your project!
Now we code!
And there you have it… all of the work that must be done before we start to write any code! It’s a lot, and it takes dozens of hours. But it is absolutely critical that you don’t take any shortcuts here if you really truly want to maximize your chances of success!
I have had founders come into my office asking for help saving a dying project, and when we dug in, I actually identified the initial point of failure right here — before coding even began. Sounds crazy, but it happens. This is really, really important stuff!
I’m here to help. I have spent my entire career guiding founders and established enterprises along the path to successful product launch. Feel free to reach out to me if you want to discuss any of this in detail. The majority of this is what I cover during the initial call with clients!