Why my first startup failed

The purpose of the article is to share my insights on why my first startup failed so that you potentially don’t make those same mistakes. There were many issues with the way I ran my first startup, however, I’m going to only list core flaws that I thought were the key players in our demise. Hope you enjoy!

Build-Measure-Learn Feedback Loop

I’m going to quote Eric Reis from his book, “The Lean Startup” because I can’t say it any better:

“Plenty of entrepreneurs focus their energies on the individual nouns: having the best product idea, or the best-designed initial product or obsessing over data and metrics. The truth is that none of these activities by itself is of paramount importance. Instead, we need to focus our energies on minimizing the total time through this feedback loop.” (76)

My first startup spent too much time chasing wild one-off ideas and didn’t take the time to learn if what we’re doing is actually working. Startups should focus their energies on validated learning, which is essentially running all of your startup ideas through the scientific method. Using the scientific method for validated learning applies to all departments at a startup – not just tech. Here’s a high-level breakdown:

The Hypothesis

The process of validating learning starts when startups focus on validating the hypothesis about the service they’re providing. This hypothesis must be fallible – meaning that you can 100% prove or disprove it at the end of the experiment.

Example Hypothesis: “My potential customers are willing to pay $10.00 a month for my service”

Setup the Experiment

Once the hypothesis is set your team, in a cross-department collaborative effort, must decide how to set up the experiment so that you can collect the data needed to validate your initial hypothesis. This may mean setting up the proper website tracking code (e.g goals in Google Analytics), sending out a survey, setting up meetings to talk directly with your target market, etc.

Execute & draw meaningful conclusions

Once the plan is in place on how and what you’ll do to run the experiment, it’s time to get out there and do it! Going off the example hypothesis, a meaningful conclusion would look like:

1. Yes, users are willing to pay $10.00 a month for my service for the following reasons…[report of the experiment backed by actual data goes here]

2. No, users are will not pay $10.00 a month for my service for the following reasons…[report of the experiment backed by actual data goes here]

The faster your startup can get to a conclusion, the faster you learn and spend significantly less time building a product no one really wants. Running all your ideas through the scientific method will give you an indication on whether to pivot or preserve the path your startup is on. The most successful startups are not the ones who have the best management, the most money, or the best engineers. The most successful startups are those that learn the fastest.

Final Notes

Knowing why your users love and hate your product is paramount to your startup’s survival. The absolute last thing you want is to not document your results and waste time doing what you knew at some point didn’t work.

Why let your marketing run an ad marketing campaign before reading documentation about a similar campaign ran last year with metrics on what worked and what didn’t?

Why spend time building & deploying an accounting software before finding out how & why your target market handles their finances the way they do? 

Please like, share, & comment!

Deploy an Angular App in Production with Nginx & Ubuntu on EC2

This purpose of this tutorial is to show you how to configure Nginx to serve an Angular app on AWS EC2. This tutorial assumes the following:

  • You already have an Amazon Web Services account (if not you can make one here) and have basic knowledge of security groups
  • You already have a purchased a domain name and have associated it with a publicly accessible IP address
  • You have an existing Angular Project hosted on a code repository (Github, GitLab, BitBucket, etc.) and have some basic knowledge of Angular

Summary of technologies used

  • Ubuntu 16.04 LTS
  • Nginx 1.10.3
  • AWS EC2
  • Angular 6.1.3

Step overview

  • Step 1 – Open an EC2 instance
  • Step 2 – Install packages and dependencies
  • Step 3 – Configure Nginx
  • Step 4 – Deployment

Step 1 – Open an EC2 instance

Log into your AWS account, navigate to the EC2 Dashboard, and select “Launch Instance”. From the list of AMIs select Ubuntu Server 16.04 LTS (HVM).

While setting up the instance, you will be brought to a page where you select the instance type. Select t2.micro (free tier eligible). Once selected, click “Review and Launch” at the bottom of the page. On the next page click “Launch” on the bottom of the page as well.

Once launched it will take a few minutes for AWS to boot up your very own EC2 instance. Store your generated key pair in a safe place on your local computer. (Here’s documentation from AWS on how to handle your key pair)

Note: You may have to adjust the security group on your EC2 instance so that your website is publicly available. There’s plenty of resources and stack overflow questions solving this potential issue.

Step 2 – Install packages and dependencies

Time to ssh into your Ubuntu server with:

ssh -i ~/path-to-your-key-pair ubuntu@ec2-your-public-ip.compute-1.amazonaws.com

Once you have successfully logged into your public server it’s time to install some packages. Execute these commands from within your Ubuntu machine:

# update Ubuntu's local package index 
$ sudo apt-get update 

# install git 
$ sudo apt-get install -y git 

# install Nginx 
$ sudo apt-get install -y nginx 

# clear out the local repository of retrieved package files 
$ sudo apt-get -s clean 

Step 3 – Configure Nginx

If you are new to Nginx I highly recommend reading the following to understand what these next steps actually do.

Common Pitfalls using Nginx

Nginx Quick Start

Nginx Configuration

Navigate the sites-available directory.

$ cd /etc/nginx/sites-available

and use your preferred editor (I use vim) to create a new file. In this case we’re storing our nginx configuration as example.com.

$ sudo vim example.com

Enter the following in your new file:

server {     
    listen 80;      
    listen [::]:80;            
    root /var/www/your-angular-app-name/dist;   
    server_tokens off;   
    index index.html index.htm;     
    location / {         
        # First attempt to server request as file, then         
        # as directory, then fall back to displaying a 404.          
        try_files $uri $uri/ /index.html =404;      

***The line root /var/www/your-angular-app-name/dist will tell Nginx where the index.html file is for your compiled Angular app.

Save your new file and symlink it to the sites-enabled folder.

$ cd /etc/nginx/sites-enabled 
$ sudo ln -s ../sites-available/example.com 
$ ls -l

Remove the default file that comes with Nginx in the sites-enabled directory. This default file was placed here by Nginx when it was installed.

$ sudo rm default

For good practice run a test on your Nginx configuration to correct any configuration or syntax errors (syntax always gets the best of us).

$ sudo nginx -t

• Restart Nginx:

$ sudo nginx -s reload

Step 4 – Deployment

Before deploying an angular application we must use the Angular CLI to create the production build that will be served on our EC2. You have the option of building the production bundle right on your local or on your live server. If you are working by yourself on a project, it’s okay to build and add the generated dist folder to git source control. Otherwise you should avoid adding the compiled dist bundle to git when working with others to avoid merge conflicts from everyone’s own build.

Angular CLI documentation on deployments

Below I will show you two ways to deploy your app. Both methods below are ok to “test the waters” to build small applications to understand how to deploy an Angular app but I don’t recommend you keep deploying Angular in the ways detailed below. It is well worth your time to learn how to build an automation pipeline that takes care of this process for you. See my article building a simple CI/CD pipeline from GitLab to AWS. (You can build and deploy your Angular app virtually free!)

Path 1: Building the production bundle locally

In the case that you are building the production build on your local you will need to run:

$ ng build --prod

If there are no errors when Angular is building the production bundle then a dist directory will be generated in the root directory (/) of your project.

Check in the new dist dist folder to source control so that you can pull it into your server.

You will then have to ssh into your EC2 and clone the git repository into the /var/www/ directory.

$ cd /var/www
var/www $ git clone https://your-project-name

Note: You may need to use the $ sudo flag if your user inside the server does not have the right permissions to run these commands.

Restart Nginx:

$ sudo nginx -s reload

Navigate to your URL or Elastic IP address and your site should be live! If all you see is an Nginx 404 page then double check the directory on the root ...; line in your Nginx sites-available file is pointing to the right directory.

Path 2: Building on the server

DISCLAIMER: Depending on how large your application is this following method can run up your cloud provider bill.

In the case that you are building the production build on your server, you will then have to ssh into your EC2 and clone the git repository into the /var/www/ directory:

$ cd /var/www
var/www $ git clone https://your-project-name

Note: You may need to use the $ sudo flag if your user inside the server does not have the right permissions to run these commands.

Now it’s time to create the production build right on the server by making sure you currently are in your source code directory. First we must install some additional dependencies on the EC2 instance with the following commands:

# install node package manager 
$ sudo apt-get install -y npm 

# install curl 
$ sudo apt-get install -y curl  
# install node.js $ curl -sL https://deb.nodesource.com/setup_10.x | sudo -E bash - 

# update node.js 
$ sudo apt-get install -y nodejs 
# install the Angular CLI 
$ sudo npm install -g @angular/cli  

Next we navigate to the directory where we cloned the repository

$ cd /var/www/the-project-you-just-cloned

Once in the project directory, you will run:

$ ng build --prod

If there is an issue with the production build then your website will display the generic Nginx 404 page. To avoid this I highly recommend testing the production build process by running the $ ng build --prod command on your local first for testing.

Once the dist folder has been built we will restart Nginx. Nginx has already been configured to look at the var/www/your-project/dist from our configuration above.

Restart Nginx:

$ sudo nginx -s reload

Navigate to your URL or Elastic IP address and your site should be live! If all you see is an Nginx 404 page then double check the directory on the root ...; line in your Nginx sites-available file is pointing to the right directory.

If you have this process down pat and want more of a challenge then check out my next post on building a simple CI/CD pipeline from GitLab to AWS.

How to preserve your static assets in the production bundle

If you want your static assets (images, svgs, etc.) to show up in production you’ll have to do the following:

  1. In your angular.json make sure that your assets folder holding your static assets is included in the assets block like so:
“assets”: [

With this addition to angular.json, you’re telling angular where to find the assets when you reference them throughout your code in the build process.

2. Make sure that you’re referencing the correct directory path to your assets in your HTML blocks. In the configuration above, each asset in the assets folder should be accessed like the following:

<img src="/assets/images/my_cool_image.jpg" /> 

Now when you build and deploy, the assets should show up because Angular knows where to find them now.

You’re done!

If you’ve followed all these steps, you’ll be able to navigate to your site domain in any browser and see your basic angular app up and running. If not, remember it can take up to 48 hours for any DNS changes to fully propagate if you’ve just associated your Elastic IP to your domain name manager! Thanks for reading!

Small Startup? Need to find tech talent?

The purpose of the article is to share my experiences finding tech talent with a small budget. If your company is a native or web application it’s absolutely imperative that you have a great technology foundation that meets your business’ needs – and is built by the right people. Here’s a list of mediums that may help you find tech talent in no particular order:

“People are not your most important asset. The right people are.” – Jim Collins

1. Meetups

Meetups are a great way of networking yourself amongst a group of people who generally have the same set of interests. Nowadays you can find a meet up that’s focused around certain technologies, frameworks or content management systems that your business needs.

Post a succinct description of the position and a way to contact you on the message boards of the groups you’re trying to target. Be mindful not to spam the groups with your job postings as you may want to check in with the group admins for guidelines regarding job postings on the group message board. The group admins may even help you reach the right people you’re looking for.


1. AngelList

Angel list is great for finding talent that’s specifically looking for startup work. Make a company profile, add your job, and start inviting candidates to look at your job posting. When you do get a match on AngelList, be proactive and quickly respond to any developers questions about your job posting.

I would not recommend posting your job on platforms such as LinkedIn or Indeed Prime for those looking for employment on those sites are probably looking for a stable job with full benefits – not a volatile startup with no guarantee of success.


3. Code Bootcamps

Contact local code boot camps in your area and ask to speak with someone responsible for making sure the new graduates are employed ASAP after they graduate. When you reach out to these schools you will have to provide them with a short description of your ideal candidate. In turn, they will send you resumes and introduce you to the candidates that you wish to interview.  The majority of the candidates will not have 5+ years of development experience, however, most are eager to learn and jump into the next opportunity if given the chance.

4. Freelancers

Leveraging the plethora of freelancers out there is a great idea. If you’ve hired a freelancer just based on a cheap hourly rate or quote, don’t be surprised when you’re about to hit a deadline and you find out that almost nothing is production ready. Simply put, you get what you pay for. It would be best if you had a tech-savvy person, CTO, or product manager on your team that can negotiate with and properly screens the freelancers. 


Final Notes

Don’t focus too much on finding someone who is super passionate about your brilliant startup idea. You may be spinning your wheels looking for the “perfect fit” who fits the exact mold of what you’re looking for. You’re much better off looking for someone who loves to build awesome things regardless of what it is they’re building.

Know of another cost-efficient way to find great talent? Comment and let me know!