Our team has expanded from 2 to 6 in a year (pretty impressive for a bootstrapped agency!) and we see ourselves bringing on a few more highly qualified developers / designers / PM’s in 2016. We think a really good # for a dynamic, boutique agency is around 10, so we’ll probably stop there for awhile if we decided to cross that road and expand.

If we do, we see ourselves having a team look something like this: CEO, CTO, PM, 2 Designers, 5 Developers (2 Mobile, 2 Back-end, 1 Front-end)


Experience: You’ll never have a Jr. developer. There’s simply too much of a learning curve in that first year of development, and time needed to get talented to do this.

All of our developers and designers have at least 5 prior years of full-time experience and many started in highschool and then studied Computer Science or Design in college.


Our entire team is comfortable with working on both the ‘front-end’ or ‘back-end’ of apps, but we all know their preference and skill level. We like ‘full stack developers’ that specialize on one thing during working hours, and practice the other during their own time.

“New” Languages

Our team loves trying out new languages and frameworks, and sometimes contribute to things we could see start to grow and take over the web. However, we prefer the “settler” approach before the “pioneer” approach for new things. “Pioneers get slaughtered, and the settlers prosper” .

Awards / Press:

We’ve been named one of the “Top Development Agencies” in Chicago, and we’ve had 5 apps be featured in the app store. Our apps are also routinely one of the ‘top’ in their respective sub categories “Sport Tickets” “CPA Exam Prep”, etc. We’re still on the hunt to product a “Top 10” overall, but it’s honestly a combination of Budget and Luck. However, we do feel as though we’ve been flying under the radar for quite some bit, perfecting our craft. We expect the rest of 2016 and especially 2017 to be really exciting. Let’s see where it goes!

Internal Products

As we’ve said before, we do not accept every opportunity that comes our way. Yes, we were more carefree in years past, but realize more and more that ‘perfect’ projects only happen when both parties are great fits for each other at the start. So, we also build our own internal products for a few reasons:

  1. To test or broaden our skill set: Rather than ‘testing’ a new framework, language, or service on a client project, we try it out on an internal product.
  2. The dev and / or entrepreneur community needs it: While we contribute to open-source projects, we’re more product minded than “straight up development”. We like to make free tools that still benefit the entire dev and entrepreneur community.
  3. Passion projects: We (like you) sometimes have burning desires to see new products come to market. Luckily, we get that opportunity!


SuperTailgate.com is a “TripAdvisor for Stadiums and Tailgates” this has been a passion project of our CEO for the past few years, and originally was built after countless customer service requests of Ticket Scalpr to provide tips and resources for what to do around stadiums for Sport Travelers.

We just launched the Beta Version, and will be focusing on improving the content over the course of the 2016 football season. You’ll see some big product enhancements for the 2017 season 🙂

Rejected App:

If you’ve asked a developer if they’ve ever had an app rejected from the iOS app store and they say “No” then they simply haven’t worked on enough apps. RejectedApp.com is a FREE resource that lists the most common reasons that an iOS or Android App will get rejected, and the ways to prevent it.

We created this FREE resource after having a few apps get rejected for really weird reasons. A perfect example was “App didn’t provide login credentials for tester”. We assumed that the tester would create an account using an Apple account to make sure they received the authorization email, but we were wrong! This only happened once, but it still was the reason an app was rejected.

If you’ve read this far, congratulations! It took an obscene amount of time to write this so we hope you’ve liked it. We’re going to continually improve this document (like a startup!) and would love your input. If you have any questions, comments, or suggestions about this document, please email us @ contact@LakeviewLabs.io

Thanks! The LakeviewLabs Team