One New Startup Per Year

A personal goal of mine is to be the seed investor & advisor in at least one new startup per year. In 2014 it was TapCue, a healthcare communications platform, and in 2015 it was ProRata, a fintech application to simplify deferred revenue recognition in QuickBooks for subscription based businesses.

Here are a few ideas or areas of interest for a 2016 investment:

  • An application focused solely on helping brand new college grads find their 1st career opportunity. At QGenda we physically attend 30+ career affairs per year ranging from as far north as Wisconsin all the way down to Florida, but imagine if we could look at candidates from 300+ schools! Existing similar idea: AfterCollege.com
  • An all in one HR application for companies with 1 to 300 employees. This application would offer automated employee on-boarding, payroll, time off tracking, employee benefits administration, employee review tracking, and several other HR specific tasks that need autopilot. Existing similar idea: Namely.com
  • Proximity based mobile app to easily provide a financial tip without using physical cash. For example, a valet driver would use the app in tip receiving mode, and the car owner would simply provide a tip by selecting the valet driver from a list of near by tip receivers.

Coming up with the idea for a new startup is the easy part, but finding the right co-founders to embark on the 8-10 year journey is the hard part.

Tips About Migrating to Amazon Web Services

Over the last two months our development team has been migrating QGenda’s automated  physician on-call scheduling application from our own fully owned geographically separated cabinets of servers, switches, firewalls, and load-balancers to Amazon Web Services (AWS) Elastic Compute Cloud (EC2). We set out with a plan to replicate our current production environment using AWS, and along the way have experienced certain glitches worth mentioning for others planning to utilize AWS EC2.

Here are some main tips and gotchas learned in our AWS migration:

  • The Elastic Load Balancer (ELB) has a default timeout of 60 seconds and drops any long running HTTP(s) requests exceeding this limit (such as generating a downloadable data intensive report on the fly). Solution: Submit an AWS support ticket asking them to extend the timeout to their maximum of 17 minutes.
  • If your application requires SSL, it’s usually always best (performance wise) to decrypt the SSL on the server instead of offloading the decryption to the load balancer. This is especially important when using AWS because decrypting on the ELB would mean your data would travel in plain text within Amazon’s network from the ELB to your server(s) which other AWS customers could potentially intercept.
  • AWS Elastic IPs (EIP) provide a static public facing IP address that can be assigned to any EC2 instance, however the EIP does not have a static internal private IP. If he EC2 associated with the EIP is rebooted, then the internal private IP changes, which can cause troubles when mirroring a database. Solution: Write a script to monitor the internal private IP or use Amazon’s VPC.
  • The AWS Developer support for $49/month is worth every penny. It provides you with email support where they will respond within 12 hours. Another great support resource is the AWS community forums.

Switching from fully owned geographically separated hardware to AWS is definitely something each business should consider. It does not always make sense for every cloud application, but for QGenda’s needs it works perfectly. Just make sure to test, test, and test extensively when moving your production environment to the cloud.

Have you migrated your application to AWS, if so, what tips/gotchas did you run into?

Twitter: @Benoit_Greg