App Development Process

Our Process

It’s a 14,000 word manifesto on how we think about and build mobile apps & digital products. Our team has worked together for the past 7 years, starting with Patrick’s first startup TicketScalpr.com.  After success with ‘Scalpr’ & freelancing for a few startups, we became known as the ‘mobile guys’ in Chicago. Over the years, we added to our team with talent that we could trust to build whatever mobile app and digital products that come our way. We’ve been lucky enough to build, or be directly involved with:

1. The Fastest Growing Company Ever
2. #1 App in Shopping
3. #1 App in Education
4. #1 App in Car Shopping
5. #2 App for Tickets 
6. #7 App in Photos / Video
7. #1 Tailgating Website
8. Multiple tech patents for our clients
9. Digital products for Fortune 100 Companies
10. And Many other featured apps / digital products for up & coming startups in Chicago & the Midwest!

We’ve seen success & failure for practically every single size company (small business, startup idea, seed, series A,B,C,D+, IPO, public, public turnaround, etc), and bring those experiences to each and every one of our apps. Ultimately, building mobile apps and digital products is our passion, and it’s something we’ll be doing for the rest of our lives!

Please keep in mind that this is generally how we build apps.  Every product has different problems, goals, budgets, teams,, and timelines. Sometimes it makes sense to launch quickly and keep iterating, but others it might make sense to do more customer interviews and try and build out a market before the app is launched (i.e for a 2 sided marketplaces). So, if you’re considering us for your next product, or just want to learn great techniques on how to build digital product, jump in and start reading!

Clients

We’ve had various types of clients over the last few years. It’d be impossible to draw a correlation between all of them and say ‘this is our client type’, so we’ve listed five categories of ‘roles’ that we play with our clients.

Napkin Startups

Our most popular client to date is a person (or team) with no technical skills that has a burning desire to fix a problem in a market through a digital product. This client is a late 20’s, early 30’s person in Chicago (mostly) that is very successful in their current or previous career, where they’ve specialized in one thing (sales, marketing, operations, etc) and work with us to build out product.  This means that we’re doing the entire project for them, & that they’d go through our entire cycle of product development, design, development, launch & growth. After the 1.0 is built, we work with them to iterate quickly & build the product through their userbase or customers.

New App for existing web-focused company.

Successful web startups and companies that already exist need to constantly iterate and introduce new products and features to stay ahead of the competition.  As they grow, we find that either the users or customers of the company start asking for an app to be made, but the company either doesn’t know how to make an app, doesn’t have the resources, or both.

We love partnering with companies like this because we get to jump ahead a few of the “product discovery” steps & build an app that perfectly fits their needs.

Dedicated “App Developers”

Similar to above, we sometimes evolve to become the ‘dedicated’ app agency for clients that have limited app needs, but still need an app.  It’s immensely cheaper to work with an agency like Lakeview Labs, where we specialize in every facet of app development, rather than try & build out that functionality in-house.  We expect this to grow within the years to come.

Re-invent an existing digital product

On the other hand, many companies already have an app in the store, but haven’t updated it in years, or just don’t even know ‘what’ changes they should be making.  These are also great clients to work with because they already know what ‘works’ with their app & probably have a large list of product enhancements that they’ve wanted to do for years.

Maintenance and Support

We provide ongoing maintenance and support to all of our clients once they launch, but find that many freelancers and other firms ‘ditch’ their old clients when something better comes their way. We’ve sadly had that happen to us before, so we open our arms to those needing support! All we need to know is if the current technical infrastructure that you’re built on is something that we support. However, we won’t work on a framework or language that we’re not skilled in, nor accept a client if the code is in an awful state.  We’ve turned down countless projects for this reason, but will review 

Tech Consulting

On a handful of occasions, we’ve done ‘digital innovation consulting” for companies looking to expand their brick and mortar businesses online. We’ve Reach out to us and we’ll figure something out that works for you!

Understand

Entrepreneurs, Startups, and Companies come to us with all different types of backgrounds and experiences. We’re quite comfortable talking about almost every type of modern technology (We live, eat, and sleep it!) but know that generally, things like apps, websites, or improving existing systems are what we’ll probably be talking about.

We’ll start off with a call or two, before we set up an in-person meeting. In our call(s) we will try to understand what you’re trying to build, who it’s for, and why you’re doing this. All this information + other information that we request will help us have better conversations going forward.

During our first in-person meeting, we typically do a bit of white-boarding, go over our process, and see if it’s a potentially good fit for the both of us.

Regardless of what you’d like to make, we will challenge your assumptions. We will discuss if the product HAS to be built on your preferred platform (Native iOS / Android, React Native, Web, or both), what your customer acquisition strategy is, and really just try and understand how we can position your business in the most competitive and best way possible.

Ultimately, we need to understand the two following things:

The W’s

1. Why are you building this?
2. Why does the Market need this?
3. Who are you building this for?
4. Who is your team?  
5. What are you trying to prove with this product?
6. What is the goal of product?
7. Where will users be able to find this?
8. Where are you in your journey with this product?
9. When do you want this to be launched? (Yesterday’s not an answer :P)
10. & many other questions that tend to start with W’s!

After we understand the above, we should both be on the same page. Don’t forget, we’re the product development, design, and technology experts, but you are the subject-matter- expert (SME).  You need both for products to WIN in their market!

Proposal

After we understand what you’re trying to build, who it’s for, and why, we will send over a range in an estimated proposal. Why a range? We’ve built apps for too long to know that it’s impossible to give you anything but a range for the first build-out of a new product. Moreover, we haven’t done a proper product development sprint by this time, so we really just have a firm “idea” of the end product.

Here are a few things that might change over the months when we’re building your product:

• Competitive Landscape: Did a competitor launch before you? This is a great time to learn from their mistakes, and to see what is done well, or poorly for their product.
• Internal Business Needs: Depending on the estimated build time, your company might be introducing a new product line, or shifting its strategy.
• New Features OR UI/UX: It’s very likely a new app or product will launch that has a feature or UI/ UX that you prefer over what we agreed on months ago.
• New Platform-specific things: Apple and Google introduce new product features all the time (Apple Wallet / Health, Pre-Built Social Sharing tools, etc) as well as other SASS apps we use.
• 3rd Party Apps: During our initial estimate, we might think we need to build custom analytics tracking (for example), but a paid service might come out that would eliminate this.

For all these reasons and many more, we will deliver a range. We do NOT sell “fixed–bid” projects, since all of our projects are custom made.  It’s simply Effort * Rate.

Contract

If our two teams come to an agreement on this, then we will deliver a proposal. All we ask of our partner is that they sign the proposal, and send us a deposit (which is a % of the total project) This % is put into escrow, and is take out from the last invoice (or two).

We require a deposit because it’s the only way that we can properly allocate our team effectively for projects. Once we accept your deposit, we ‘lock-in’ that time period for the members of our team who’ll be working on it.

Yeah! Now that we’ve completed all of that, we will set up our sprint design meetings, and will have a rough roadmap of everything to come.

Yes, most companies and agencies start with design, but we find that this generally leads to more failure than success for new and improved products.

Why just ‘mock up’ something before you truly understand who your customer is, why they’ll use this product, how they’ll use the product, and what that problem is you’re trying to solve?

Competition

We’ve already learned a bit about the problem you’re trying to solve during our “Understand” phase, so now we need to understand who or what is solving this problem currently in the market. To simplify things, let’s break up competition into a few categories:

• Product Exists in the Market: There is a similar product that already exists in the market, but yours has its own unique spin. It could be cheaper, faster, better usability (UX), better design (UI / Aesthetics), new platform (mobile for example)
• Hacked together product exists in the market: Users use existing platforms or processes to get their desired action. A great example is Dropbox, and what people had to do before it (and similar apps) were launched. Before these cloud-based platforms, people had to either a) Email themselves a document b) Save the document on a “flash drive” c) Use a virtual machine d) Print the document e) Make up a crazy excuse why they forgot it.
• Product does NOT exist in the market: We expect to only come across a handful of these each decade. Before this product existed, the actual activity was not possible, and it might be hard to explain what that product is to non-technical people. Essentially, this new product is so drastically different that it enters the “10x Principle” by Peter Thiel, Examples include: iPhone, Email, Car, Computer, Phone (Landline), Skype, Cloud Computing, etc.

We have no preference or major opinions about any of these and do know that most truly innovative companies are in the 1 and 2 categories (and learned from the failures of 2 and 3). A few tech companies that were not the first, but were the last include Facebook, Google, Groupon, Amazon, Uber, and Apple.

It really doesn’t matter where your idea, product, or company currently is, we will work with you to understand your competition and how to position yourself correctly.

Understand your Competition

Leader

1. Who is the leader and why? (Market Cap, or revenues doesn’t necessarily mean they’re positioned correctly)
2. How did the leader(s) get to top?
3. How technical is the leader?
4. What’s their Competitive Advantage?
5. How did they create this?
6. What’s their angle? (Cheap, Quality, Quantity, Customer Service, etc?)
7. What’s their estimated market share?

Market

1. Where is the market going?
2. When do you expect this to happen?
3. What could totally disrupt the market?
4. Who else could come into this market
5. How do you fit in this?

Many new innovative apps and ideas fail to do just one thing well, so we’ll work with you to nail that one thing, before we try to do 100x things well.

Now that we understand all this, we discuss how to make your product compete and become a Purple Cow.

The 5 W’s

We like to keep things simple when building a product for the first time. We’ve decided that the 5 W’s of Who, What, Where, When, and Why are great questions to ask when building a product for the first time. Read on to see why!

Who are you building this for?

We need to establish who the 1.0 is for, not the 2.0, 3.0, 4.0….

For Example, Facebook started as a “social media network” (before that term existed) for Harvard, then expanded to other Ivy League Universities with very limited functionality. Eventually, they opened up to other universities. It was years later till they opened it up to the world! >

Yes, goals and long term plans are very important, but if the 1.0 isn’t successful, then the next few versions ultimately won’t matter. We need to have a crystal clear idea of WHO we are building this for.

A few common things we hear when we ask potential clients:

1. Investment: Some entrepreneurs think that a 1.0 will allow them to get an investment from investors or VCs. In the 2000s this was maybe the case, but the only time we really see this happening is when entrepreneurs have a prior relationship with investors, and have already discussed this scenario happening. (Not suggested…) For those with no prior experience, you should not be thinking about investment, but how to build something that’s “Too good to ignore”.
2. City / Regional Market: This is a good starting place for most companies. It’s easier for logistical, partnership, and many other obvious reasons. If you live in your market, you understand the culture + quirks of the region, and will have a much better chance of success. Don’t forget, it’s easier to put out fires when you’re nearby, and everyone likes to root for the home team 🙂
3. Niche Market: Also a great starting place for most companies. A great example of this is one of our favorite clients, Little Nugget. Little Nugget is an “Instagram for Baby Pictures”. We did not start with “A better Instagram” but created a niche inside a platform that already exists, and then focused that Niche to a particular thing. (Not all children, but Baby, Pregnancy and young toddler pictures)
4. Regional, Niche Market (Optimal for Marketplaces): Many companies have some component of a marketplace (supply and demand) so the combination of a regional market inside of a niche is sometimes the perfect blend to get your product growing. We need to find a dedicated and growing group that will be your early adopters and will love what you’re trying to do.

What need will this satisfy in the market?

What’s the current status of the problem in the market, and how are people solving it? Is this product improving something that already exists? What’s the scenario?

Keep in mind that we need to figure out if this product will actually solve the original problem, and if it’s much better than what is currently in use.

For example, if you came to us with the idea of a “Groupon for Kids” so parents could save money on toys, activities, etc, we would need to figure out if the “Groupon for Kids” model actually solves that problem, OR if you’d get steamrolled by Groupon if they decided to introduce a filter for “Kids”. So, it might make sense to have an app (web or mobile) for parent’s to save $, but not setup exactly like Groupon. On the other hand, it might make perfect sense! Everyone situation is different.

Where will users be able to find this?

After we decide on the platform and why, we should establish a few of the places we expect to get customers. Will it be SEO, PPC, Mobile ads, ASO, Viral, etc? We’re not trying to set the exact marketing plan here, but make sure we don’t build something that will limit one of our main acquisition channels.

For example: You’d like to make an e-commerce site and think that SEO will be a main driver. We need to make sure that we’re optimizing for on-page SEO things, but also aren’t hiding any content behind a “Sign Up” by the user. >

When do you want this to be launched?

We live in a world where many things are instantaneous, but if we want our product to be built well and to scale properly, we need to make sure we have enough time to build. Yes, we build very quickly and efficiently, but there’s only so many hours in a week.

We need to figure out 2 things here:

1. Are you trying to hit a deadline for a conference, big event, or other specific
2. If so, is it OK that the product is in an Alpha / Beta status?

Sometimes we’re at 100% total capacity for the team. This means that normally we’d be able to hit your deadline, but we put a priority on all of our current projects over potential. We’d expect that you’d like your project to have the same time and respect.

However, none of the above really matters if we have too small of a time window initially. We don’t like to rush things that shouldn’t be rushed. We’ve tried it in the past, and in the end, no one is happy. We want to make your product as successful as possible, so come to us early with your ideas!

Why are you building this?

Tell us why you’re building it.

1. Is this an inner passion?
2. Are you trying to make sure your company doesn’t get out-innovated, so you can maintain your position in the market
3. Is your current website or app old, and it needs to be brought to modern standards?
4. Something completely different than what’s listed here?

We expect 100% totally different answers for every project, so just be straight-forward with us!

Success

We now define what Success means to you. Yes, we actually care about the products we build and expect them to be successful. This is one of the main reasons we DO NOT accept every project that comes our way.

We start by asking how the company will measure success. Most companies haven’t put much thought into how they’ll measure the success or failure of a product, so this puts many clients at pause when we first ask it. Typically, a client will ask us how we define it to start, but since we work on so many different products, with so many different companies at completely different stages, it’s impossible for us to give a clear answer. What might be a grand-slam for one entrepreneur, might barely be a single for another.

If you’re a bit confused about how to define “Success” here are a few of the last few weeks for different projects:

1) “Help us scale our app from 25k users a month to 250k” 2) “Setup a landing page website for a new promo we have coming up” 3) “Build an Android app with the same functionality of our iOS app. We want to have as good or better metrics as our iOS did in its’ first three months”

So, it’d be hard to give a concrete answer to how we’d measure it for you right now, but the following is an example of how we’d measure success using metrics for the first few versions (1.0, 1.1, 1.2 +) of a B2C app-

Metrics

It’s pretty easy to measure digital things these days, so we can establish “KPI’s” (Key Performance Indicators” that we’d like to hit in the first month, week, daily, etc. The most important thing is GROWTH!

1. Total Users: How many total users have either signed up or came to the site / app
2. Active Users: How many users are using the app daily, weekly, monthly, etc?
3. Virality: Are users sharing the app with other people?
4. Acquisition Channels: Where are the users coming from?
5. Total Revenue: How much does the app make daily, weekly, monthly, etc?
6. Revenue per Customer: How much is each user spending?
7. Repeat Purchases: How many users are making multiple purchases?

But, we wouldn’t forget that this:

1. 1,000 Total Users
2. 500 Active Users
3. 250 Purchases
4. 50 Users have made a repeat purchase.

Is always better than this:

1. 25,000 Total Users
2. 1,000 Active Users
3. 500 Purchases
4. 50 Users have made a repeat purchase.

The first example shows you that you have a great product, the second shows that you aren’t converting high enough, or your product isn’t as good as you thought (relatively speaking).  It’s always better to have a small number of dynamic users that you can learn from. It makes analytics/data collection easier & changes more impactful.

Yes, this is really generalized, but is how most companies should define success and iterate quickly toward their ultimate goal!

Success Final:

We hope we haven’t lost you yet! We expect success out of every product and company we work on, and take it personally when things don’t work out as planned. We like to be as transparent as possible (Check out 16 in 2016 for example) and will share all of our experiences with both successful products and failures with you to make a great product.

Product

We’re not fans of describing products as “MVP’s” anymore. (you’ll hear us say 1.0) We feel as though the term means WAY too many things to different people and is all up to interpretation.  This term has started to adopt the following definitions:

1. Minimum Viable Product – A lean, mean, workable product that achieves customer adoption and allows the team/entrepreneur to learn. It does one thing “Great”, and the company waits until the product is live to introduce more features.
2. Minimum Viable Product – A semi-lean product that does everything that #2 does, but has a few “added features” because the company thinks they’re necessary. It typically does one thing Great, but it’s hopefully not hidden from the customer.
3. Minimum Viable Product – A bloated product that does a lot of things “OK”, but nothing “Great”.
4. Minimum Viable Product – A product that is not bloated, but also does nothing ‘great’.
5. Plus many more variations that are NOT what #1 is.

For some reason, many potential “MVPs” we come across just want to be “cheaper” versions of a market leader. For example:

We’re AirBnb, but cheaper”.

(9/10’s it’s too little too late for these companies..)

A strong 1.0 is what you should be building no matter what stage your company is in. It’ll allow you to build and iterate faster, will be less expensive, and you’ll get a better end product.

Core

How do we decide what goes into the 1.0? We build off of one single, strong solution (or core) that the app does better than anything else in the world. All great companies started with a strong core and it’s where their users spent “80%” of their time

Here are a few examples:

Instagram:

1. User can take a picture and add a filter
2. User can add a comment to picture
3. User can set the location of their photo (a carryover from their pivot)
4. User can “Favorite” other photos, or write comments.

Groupon:

1. User sees one Business a day with a discounted ‘deal’
2. Users have to collectively (as a Group) reach a ‘tipping point’ in order for their purchase to go through
3. Users get their ’deal’ emailed (PDF) to them

Twitter:

1. Users can “tweet” a public, 140 character message.
2. Users can follow other users to get and read their messages
3. Users can comment on other Tweets

Uber:

1. User can press one button on the Uber app to get a car to come to their address.
2. Users are charged time and distance, through the app.
3. User gets out of car and ride is completed.

The above are all billion+ dollar companies started with a few people and a simple product. They had a minimal product that did one thing GREAT.

They smartly spent more time figuring out how to get more users, and slowly added features as customers demanded them.

We know that you want to build the core, but try and not get caught up in all the other cool things that the app ‘could’ do. We should spend more time improving the core experience (UX, UI, etc) and add supplementary features as time and budget will allow.

A simple way to decide what features your app needs to make sure the app has a sufficient core + can be GREAT at doing that is to make a “Must Have vs Nice to Have” feature list.

Must-Have vs. Nice to Have

Now that the core is understood, we can start figuring what the “Must Have’s VS Nice to Have”s” are on your product development roadmap. Put simply, we need to establish the things that HAVE to be in the app at launch, or it would be incomplete.

For example:

Must Have: User can sign up for an account with email and/or facebook (i.e one method) Nice to Have: User can sign up with Email, Facebook, Twitter, SMS, and Google+”

OR

Must Have: User can pay with a credit card inside the app
Nice to Have: User can sign up with Email, Facebook, LinkedIn, Twitter, SMS, and Google+”

Every situation is different, but we need to figure out if these extra features are in the product’s core, or they simply supplement it. If they supplement it, it can wait till a 1.1+ version, or never…

Design

Our very first step in the design process is to ask the client to make some quick mockups of how they’d like the product to function. Some of our clients are initially put off by this, but it’s an exercise to understand how they envision the initial flow of the app’s core and to reaffirm what is important for the app.

After we get the ‘core’ of the app drawn out, we then ask the client their favorite:

1. Top 3-5 Apps for Usability / UX
2. Top 3-5 Apps for Design / Aesthetics
3. Top 3-5 Apps in their Market / Industry

We also find a few similar apps in a related industry and will provide a few of our favorites, but this is just another exercise to understand what the client finds important.

For example, if you wanted an “Uber for Waffle Delivery” we’d first mock-up Uber, but would then include GREAT companies using this model such as a “Uber”, “Uber for Flower Delivery” “Uber for Helicopters” etc. (if applicable)

After we determine the basics of what is expected by the client, we then start our first true design phase, User Experience.

“If you don’t have people that care about the usability of your project, your project is doomed. Jeff Atwood – Co-Founder Stack OverFlow

What is it?

The User Experience (UX for short) is how users interact with your product.  It took a while for the digital design world to embrace (we have no idea why it’s taken this long)

User Experience Design is often overlooked by the normal person because great user experience isn’t even noticed by the user. It just feels right.

A good non-tech example that hopefully makes sense are cup holders in cars. Master designers who think about the UX of a product first, put them in not only easy to reach places, but they ‘hide’ them in locations that don’t interfere with the other usability of features for that car. If you’ve seen a car that has cup holders in the doors, on the armrest in the back seat, or has one large cup holder for Super Sized Orange Mocha Frappuccinos size drinks in the front,

then you should know what we’re talking about.

However, the very best designers also know who the end customer is of the product. For example, there are a lot more cupholders in a Toyota mini-van than a Bentley Phantom. The minivan has big, basic, cup holders that are easy to put a drink into. They also tend to be very visual, so the target customer (families) don’t miss and spill when they use them. However, a Bentley hides & makes the experience of the cup holder elegant.

To summarize this example, it’s not just the total # of cup holders, the size, placement, nor reachability, but the combination of all these with the end customer in mind.

We hope that example didn’t lose you!! A one sentence explanation is “The process of enhancing user satisfaction by improving the usability, accessibility, and pleasure provided in the interaction between the user and the product.” (wikipedia)

UX First Steps

As long as you haven’t skipped chapters, you know that we’ve already gone over how we determine the basics of the app, we have some idea to what problem we’re trying to solve, and also know a bit about the industry. However, we need to understand how the problem is currently being solved, and how that can apply to what we’re creating to make the best user experience possible.

User Experience Factors

1. Platform: Each platform or operating system has an expected way of the UX of certain functionality. iPhones do not have have a physical button, whereas Android does. This slight difference is a huge factor in how Android apps should be different than iOS.
2. Current Methods: What is the current method of buying, selling, or doing whatever process your app is trying to improve? What can we learn from this, and how can we improve?
3. Competition: Is there already someone in the market? What does their app look like? How do they solve the problem? Do they solve the problem? What do customers like about their version? Customer: Does the customer truly want to change their current methods? Is your experience that much better? Does it really solve a problem for customers?

We ask these questions to confirm that we are not only solving the customer’s problem, but we’re doing in a way that is much better, cheaper, faster, smoother, than their current method in an easy to consume format.

Rough Wireframes

Our very first step for our UX is doing very rough wireframes freehand with a pen and paper. It’ll most likely be on a yellow pad since Patrick does the initial freehand wireframes with the client, and it’s his preferred design weapon. We go through rapid iterations, and we focus on the core of the app. (This is an extension of the product development process more than true UX work.)

Product Wireframe

After the rough wireframes, we will create wireframes that start to resemble the end product through a design tool such as Figma, which also serves as our main tool for designing the interface.  We do both on the same platform for consistency, but also to sharpen our skill level.  We don’t see much point in jumping between countless UX platforms (like Axure, Balsamiq, etc) when the goal is to understand the flow of the experience & general placement of elements.

We then have a UX sprint meeting with our client where we go over our UX findings & proposal & take feedback.  There generally isn’t too much pushback at this stage because we follow conventional norms to make sure the product shines.

The one thing that we should note here is that we spent considerable time planning this site before the first web version was produced, and we also had some brand guidelines and the cityscape completed.

People call it many different things, such as the “UI” “Visual Design”, “Graphic Design” “Aesthetics” but it’s ultimately “How it visually looks” and we need to make it look appealing to our users..

“Good Design” is a bit like “Good Art”. Everyone has an opinion, and many take really hard stances on what’s good and not. However, most of the things we work on appeal to a large audience, or to an audience in a niche that someone understand very well. Yes, everyone has their own preference, but we play to the average and keep everyone happy. This is one of the few times where we act like politicians 🙂

Like almost everything in this playbook, there’s way too much that goes into the section to truly cover it properly, but here are some things (in no particular order) we always consider that should go into an app design:

Imagery

Big Beautiful Images have taken over the web over the past few years for good reason. Consumers to buy with their eyes, and the human brain can recognize and interpret images 1000’s of times faster than text. Crappy stock photos are so 2004, and custom branded photos are and will be the future.

Size

The size of the elements on the screen can make a big difference in the end result. Small and thin menus might create the illusion that the product is more ‘sleek’, where big and bold might be more sporty or childish.

Texture

There was a HUGE debate about what was proper web/app design when iOS 7.0 came out 3 years ago. The debate was over “Flat” vs. “Skeuomorphism” design in apps. Skeuomorphism is trying to create a design that mimics real life in art. For instance, in the ‘game center’ on iPhones, there was a green ‘felt’ looking background like a billiard table. This was replaced with sharp, bright, and ‘flat’ design that in hindsight, looks so much better than what was the norm for the first 5 years.

Spacing

Spacing is a something that’s been talked about indirectly quite heavily the past few years with everyone saying “Clean” and “Simple” as how they want their apps designed. This is also a direct reflection of Apple’s design standards.

Navigation

Yes, this is more of a UX issue, but how the navigation is designed is also important. For larger or enterprise apps, the user might spend a decent amount of time navigating from page to page, so how this is highlighted to the user is very important.

Call to Action

Similar to the Navigation, this isn’t necessarily a ‘Design Standard” or something of classic design, but we are building apps, not Picasso’s 😉 Every landing page and most consumer apps have various call to actions that direct the user on what path they should be taking to complete an ‘action’. It’s usually built around either a purchase, engagement or something that will grow the app.

Platform

Designing for the platform might be the most important thing on this list because most of the other things are subjective to the user. Each platform we build for: web, iOS, Android, Mobile Web, etc, all have their own preferred methods of UI / UX, and in order for the app to look good and perform correctly for our users, we need to know what platform it’ll be built on. For example, android users get very annoyed when they notice that there are iPhone elements in their android app. It ultimately makes the app much ‘cheaper’ than the designer ever intended.

Buttons

Buttons are a critical part of digital design and go hand in hand with the call to actions. Buttons make it much easier for users to access different features of apps, because ‘links’ are typically too small for a mouse or a finger. We typically offset the color of buttons to make them more prevalent if they are a call to action.

Colors

Color is obviously important to web design and have a lot of psychological and theory behind it. Here’s a great article about it. We’re shocked how much of the web is ‘blue’ but we’re starting to see more colors get some traction. “Yellow and Green” are two colors that come to mind!

Typography

Last but not least, is Typography (font for you nondesign folk). Typography is the one thing that most people new to design tend to overlook, but it can truly make a world of difference to the end result of an app or website. Unless there’s a specific reason, almost every app can (and should) use two fonts; one for the headliners or navigational things, and one for the paragraph text.

How we do it

By this time, we’ve met the client a few times and they’ve told us what type of ‘style’ they like, through either conversations or examples of their favorite apps. Unless the app it’s a B2B app or for outlier cases, our screen is the “Login screen.” We find that most logins should look the same, so we use it as our ‘base’.

For most apps, we make 1-3 versions UI Login versions and will let the client share it with friends and family for feedback. This step usually doesn’t take more than a day and is typically a quick ‘Yes!”,“No!”, or “Take this from this, and then it’s a Yes!”

We then begin the design of the CORE. An easy to understand example would be a photo-taking and picture sharing mobile app.

1. We would start with the camera page (filters + anything special)
2. Photo confirmation
3. Share screen
4. Photo feed

We then design the supplementary pages of the core. This could be things like old photos, deleting photo page, the menu, and any other pages to complete the 80% of the functionality

After this, we really kick the UI / UX into high gear! We’ve already done our UX and the UI standards have been accepted. We start improving the core (don’t forget Core = most important pages) and then move onto the prototyping stage.

Therefore, the goal of this phase is to make sure that we’re on the same design path the client would like, without wasting time and $ on building and branding the entire app and making changes later.

Yes! We’re now making real, tangible progress in the development of our product, and we can start to get more, real feedback on our progress so far.

Yes! We’re now making real, tangible progress in the development of our product, and we can start to get real feedback on our progress so far.

We use tools like Figma, Zeplin, or Marvel to share our design with either potential users or a much bigger testing group. Here are a few great benefits:

1. Ability to create a clickable prototype: Testers can actually swipe, tap, and navigate from page to page.
2. Ability to invite a large amount of testers with just a link: We can invite a huge audience to give us some feedback on the core of the app. This could be anyone from the internal team, to friends, or even actual potential customers.
3. Testers can comment on specific buttons or areas of the page: Instead of generic ‘this page needs some work’ they can show us exactly what they’d like to improve on.
4. We can swap out new slides of changes for the same testers if we need to change anything.

Yes! We’re now making real, tangible progress in the development of our product, and we can start to get more, real feedback on our progress so far.

We use tools like Figma, Zeplin, or Marvel to share our design with either potential users or a much bigger testing group. Here are a few great benefits:

1. Ability to create a clickable prototype: Testers can actually swipe, tap, and navigate from page to page.
2. Ability to invite a large number of testers with just a link: We can invite a huge audience to give us some feedback on the core of the app. This could be anyone from the internal team, to friends, or even actual potential customers.
3. Testers can comment on specific buttons or areas of the page: Instead of generic ‘this page needs some work’ they can show us exactly what they’d like to improve on.
4. We can swap out new slides of changes for the same testers if we need to change anything.

Feedback

We suggest our clients to get feedback with the prototype at this stage. Sometimes when you stare at the UI/ UX of an app for weeks and weeks, you make little lies to yourself like “anyone would understand this”.

That’s why we think this is a great time for a potential reality check before we keep progressing and finish the other parts of the app. If the feedback is generally positive – we shoot for 7-10’s at this point – then we know we’re on the right path.

Here are some things we ask testers to get better feedback:

• What’s your immediate reaction to this page?

We’re trying to pass the “quick look” check. Many potential users of a product will only give something a few seconds of their time, so we want to make sure whatever w’ve made makes an impact.

• What do you think this app does?

We want them to describe the functionality of the app. A perfect response would be something like “I think this is like an X but for Y” OR “This seems like an AirBnB but for Dogs”.

• Could you please complete XYZ? (the most important function)

Since our prototype is clickable the tester should be able to complete the most important functionality of the app. If not, then we improve on that functionality

• What do you hate?

We’ve found this to be the most direct and effective way to get criticism. No one will say it’s perfect, but we also want to make sure the tester knows we explicitly want them to tell us what and why they hate something.

• We also have the tester alk aloud as they go through it

We have our testers verbally say the things that are going through their head. We make them keep talking until they’re done, and don’t say anything even if they ask us questions.

We take all the feedback we’ve gathered and try to find the few things that people are all saying in agreement. If there is anything consistent that’s a negative, we revise in our second round of UI / UX.

UI / UX Round 2

Now we’re really moving with our design! There are two goals with our 2nd round of UI / UX.

• Address anything that came up after the first feedback cycle

Yes, it’s not smart to always make changes after someone gives you feedback, but if it’s a consistent problem from multiple people, then it’s probably a result of us understanding the app so well that it’s hard to put ourselves inside the testers shoes. We take this time to fix whatever that issue is.

• Start the ‘other’ pages of the app

By this time, we know what major changes (if any) we need to make for the app, so we can start working on the inner ‘other’ pages of the app. This could be pages like the reset password, settingss, How it works, etc.

Prototype Round 2

In our second round of prototypes, we will re-share with our first testing group, but also bring in a new group. We make sure we’ve fixed the first problems we uncovered during Round 1, but also go through the same feedback process as we did for the first group.

As long as nothing major comes up, then we keep moving forward and address any small edits that came up during the evaluation or any other ‘other’ pages of the app.

Demo

Yes! We’ve completed our last round of feedback with the prototype, and we’re nearing the finish line for our design sprint. We tend to do one last demo with our entire team, the client’s company, the testers, plus a few alpha users (if applicable). We’ve already gotten a ton of feedback, but we’re just doing our last triple checks to make sure everyone is in agreement with what we’re building, how it’ll look and function, and who is the end customer.

We’ll send out another build, and make sure no one wants any changes. Don’t forget! It’s very cheap to make design changes at this stage, but if we decide to re-do a page after we’ve coded it, then it’ll take much more resources.

Woohoo!

We’ve finally completed our UI / UX / Design sprint! We typically will crack open our favorite beer or scotch 😉 for a quick celebration. We don’t celebrate for too long, because now the real fun begins, development and customer acquisition.

Tech Stack

Now that we’ve completed the product development, design, and a handful of feedback cycles, we’re ready to figure out the inner workings and technical infrastructure that we’ll be using for the product.

Mobile App Development

Are apps dying? (lol)…No.  We read all the same articles as you probably do about mobile. Many love to say “Mobile is dead” and “Apps are a thing of the past” but there is ALWAYS going to be a need for native, mobile apps for mobile phones in their current form.

The upcoming IOT (Internet of Things) revolution will need mobile apps to interface with the ‘things’, and there’s always going to be innovation in the mobile space. However, we could see the ‘traditional’ app changing and users only needing to download the ‘core’ of the app.

For example, how many times do you look at the “About Us”, “Terms of Service” “How it Works” or other pages for your favorite apps? Even things like “Login and Signup” are temporary pages for most apps.

Essentially, we see more web-based functionality through mobile, simply because of the ease of webviews if there’s a corresponding web app.

Native iOS Development

iOS Apps (The apple development platform) has been our specialty since we started on mobile way back in 2011. It’s the platform that we launched Ticket Scalpr on, our first client, and practically every single other app that we’ve created over the last few years.

We develop our apps using Swift, which we adopted after we felt it became stable.  The first iOS programming language was objective-C, which is what we used for the first 3 years of our existence.  Now, we always being projects with either Swift or React Native & won’t accept clients that want us to build from their original objective-c base.

Everyone on our team has at least some version of an Apple product, Patrick alone has 6 iOS devices (iPhone 5, 5s, 6,6s,7, 11Pro, and an iPad!) to make sure we’re compatible on all device types.

We expect the Apple / iOS dominance to continue for years to come.  The ecosystem is getting stronger every year & more & more options are being added to the developer suite, such as Apple Authentication, ApplePay & similar.  Exciting times to come!

Android App Development

Typically, after we see product-market fit from our client’s iOS apps, we build and launch an Android app. The problem isn’t so much that “iOS is better than Android” but it really comes down to numbers. At the time of this writing, iOS users spend a significant amount more on apps than Android users, and even our clients typically have iPhones. For these reasons, we have yet to launch a digital business only on Android, but always ‘follow up’ with it, or build it through React Native.

Android development is very similar to iOS in terms of how it interacts with an API. Yes, it’s a completely different programming language and framework, and all the tools are different (Xcode VS. Studio) but the actual app itself isn’t too different. We find that these are the two major differences between iOS and Android Apps.

1. Native Back Button: If you’ve never owned an android phone, but have used a friends, you’ll notice an arrow near where the circle button would be for an iPhone. This is used to go back a page and is similar to the back button on the web. The one thing that developers need to decide on is the actual action that hitting the back button does if it’s back to the main menu, or back to the previous page the user was on.
2. Navigation Bar: The top bar in Android can sometimes do a variety of tasks, but also just looks different than iOS. Typically, in iOS it’s just the title of the screen and a back button, but it’s starting to evolve to allow for more screen space on content.

For years, we developed using java & started to launch Android-only apps with Kotlin (developed by Google) in 2018.  Kotlin, like React Native, has a very interesting product roadmap & we’re excited to see where the Android ecosystem is headed!

Multi-Platform App Development (React Native)

For the first 6 years of our existence, if we were tasked to build an app for a client, we were asked to do a native iOS app. 

The reason for this was that for many years, hybrid apps just didn’t “feel” like a native mobile app. Hybrid apps were generally all cloud-based javascript apps that always needed some extra milliseconds to compile & translate the request into their own platform (such as ionic, xamarin, or similar) The transitions weren’t smooth and developers couldn’t partake in the full suite of tools that native apps utilize. We never wanted to make subpar apps (even w/ the bonus of being on Android) so we rarely suggested this to clients.

However, this all started to change with the release of React Native by Facebook in 2015.  In 2015, Facebook released the 1.0 of its open-sourced framework “React Native” for multi-platform app development.  This came after their failure of launching an HTML5 app in 2010, where the experience was extremely laggy & non-performant.

We gave the platform 4 years to mature & in 2019, we launched our first two React Native clients & started work on others.  We feel it’s strong enough, has enough open-source tools, & enough API documentation from 3rd party services to 100% rely on it.  We’ll continue to focus on React Native development in addition to our native development using Swift & Kotlin.

Back-end /API Development

The back-end is the engine to your app & powers practically all the functionality & data flowing into your app.  As the ‘app’ ecosystem has matured, we’ve noticed (& have led some of these trends) to make our apps ‘lighter’ & more reliant on a backend.  We do this because it allows all the ‘logic’ to be used on both a web & app platform, but it also allows us to move faster while developing our mobile apps.

However, more often than not, we aren’t building out backends for our clients.  It’s not that we don’t know how (it’s actually how the team all got their start in development) it’s just most clients come to us with an API or ‘backend’ already created.  So, if that’s the case, then we make sure the API is documented & accessible for us to tap into. If not, then we’ll have a few meetings w/ the backend team & figure out what other API endpoints need to be created for us to pull from their backend.

Either way, we always make sure the backend (or API) is always tested, fast, and reliable so there aren’t any interruptions to the mobile app.

Node.js

If we are tasked with building out an entire app & we can’t rely on Firebase, then we build out our backend using Node.js.  Node.js is an extremely fast & reliable backend that can even power apps that need real-time functionality (such as peer to peer chatting) so we decided for it to be our main language, after using Ruby for so many years.

Firebase

We LOVE Firebase.  Firebase is “Google’s mobile platform that helps you quickly develop high-quality apps and grow your business.” Firebase gives you functionality like analytics, databases, messaging and crash reporting so you can move quickly and focus on your users.  We started our love affair with their ‘crashlytics’ platform (which they acquired) but we now employ it for A/B testing & most other product functionality that an app needs. Another important thing is that it’s built on Google infrastructure and scales automatically, for even the largest apps.

We could talk about Firebase for a long time, but their site explains it better than us!  firebase.google.com

HTML/CSS

It’s impossible to create a web-based product without these internet bad boys!

Front-End Development

Almost every modern Front-end of a web-based application is going to be composed of 3 things, HTML, CSS, and Javascript. While there are different flavors of each and different frameworks on top of them sometimes they will almost always compile into those 3 things. Here’s what we use for our apps:

Javascript

We write standard javascript for simple websites, otherwise, it’s going to be apart of Angular. We consider ourselves experts in all things js!

HTML/CSS

It’s impossible to create a web-based product without these internet bad boys!

Angular.js

Angular is a complete open-sourced Javascript client and server-side web application framework. We use Angular as the framework for almost all of web-app dashboards. We picked it over ember.js simply because of preference, but we see Angular ‘winning the battle’.

WordPress

While we specialize in Mobile Apps, we’ve made some amazing websites using WordPress, such as SuperTailgate.com.  We use it for websites we create (such as this one!), blogs, & also as the CMS for apps that have a ton of content.  WordPress powers ⅓ of the internet & isn’t going anywhere!

We use Agile methodologies every day and on almost everything we do. For software development, we have our own flavor of Agile that combines a few practices from Extreme Programming and some others from Scrum.

Scrum

This methodology helps carry out projects successfully by providing tools and metrics to organize and measure the performance of teams.

Roles are one of the three most important things to have clear during development. We identify two roles with different responsibilities: The product owner, or just the client, is the one responsible for putting together and prioritizing the functional requirements, also called user stories The development team is the people accountable for creating the features in a timely fashion.

Sprints

Sprints represent one cycle in the development process, where one or more user stories are worked on. Sprints start with a planning meeting and end with a review meeting one week later. Scrum meetings take place every day in between. Both the product owner and the development team must attend all meetings.

User Stories

User stories are short, simple description of a feature told from the perspective of the person who will be using that feature. They typically follow this method:

As a “type of user”, I want “some goal” so that “some benefit”.

You’ll potentially see 100’s of stories for your product, and we establish them in a compounding and chronological order during the initial setup. They are assigned to sprints by the product owner during planning meetings, then reviewed at the end of the week

Effort Points

The development team will estimate the ‘effort’ of completing user stories, this way determining how many fit into the sprint. During sprint planning meetings, user stories are given numbers based on difficulty, based on the Fibonacci scale:

• 1: Very easy
• 2: Easy
• 3: Normal
• 5: Hard
• 8: Very hard

Test-Driven Development (TDD)

Test-Driven Development (TDD) is the most important discipline that we’ve implemented. Besides being required in any software development process, there’s a myriad of benefits. Thoughtbot summed them up quite nicely here:

Business benefits of TDD: 1) Deliver more value, faster 2) Always ship working software 3) Adapt to change quickly

Code benefits of TDD: 1) Readable specs and code 2) Clean public interfaces 3) Decoupled modules

Process benefits of TDD: 1) Regression safety net 2) Fearless refactoring 3) Team trust

At a high level, how to test is very simple: 1) Write test first. 2) Run code against the test 3) If test still works, commit!

Code Reviews

Code Reviews are a very necessary step in proper web and mobile development. Think of it like peer editing a paper or something you wrote. Even if you’re a terrific writer, it’s still good to have someone else review what you wrote to make sure it’s grammatically correct and makes sense.

Here are our Pull Request Steps:

• Create a local feature branch based off master.
• When feature is complete and tests pass, stage the changes.
• When you’ve staged the changes, commit them.
• Write a good commit message.
• Share your branch.
• Submit a pull request.
• Ask for a code review.
• A team member other than the author reviews the pull request. They follow our code review guidelines to avoid miscommunication.
• Reviewer makes comments and asks questions.
• When satisfied, they comment on the pull request “Ready to merge”.
• Merge and deliver.

Projects can go sour for a variety of reasons, but we feel that communication is time and time again the main culprit. Here’s our simple, but strict method of communication with clients and internally.

Daily Standups

Every Tuesday and Thursday (every day for huge projects) we have a 5-15 minute “Standup” with the client, where each developer or designer discuss these three things:

1. What we worked on yesterday: The developer will discuss the feature(s) that they completed the previous day.
2. What we will be working on today: The developer will discuss what they plan on completing that day.
3. If there are any “blockers”: Blockers are things that will block the development team from progressing and finishing their user stories. A good example might be “We need the authentication credentials for that 3rd Party analytics service” It’s then up to the project manager to ‘unblock’ the developer by getting those credentials, or just asking the client to create an account and send over.

Sprint Planning Call

We have a 15-30 minute sprint planning call (we shoot for 15 minutes) every Monday where we have a ‘high-level’ of the previous week, talk about we are planning on accomplishing that week and to figure out any blockers for the development team. It’s ultimately a more powerful standup if the project management was setup correctly from the start.

Sprint Review Meeting

We only save these for our ‘Huge’ projects, and really don’t like to have them too often. We consulted with a startup that did these once a month, and calculated that the startup lost about $5k every meeting…This was a unique circumstance because the firm was paid hourly (so the more people on the call the better) but we found it just terribly inefficient and unethical for various reasons.

So, when we do have these meetings we only ask for ‘representatives’ from different departments to show up, and then send meeting notes to the entire team afterward. We timebox it from 60-90 minutes and make sure there’s a strict script to follow and anything that needs to be demoed is properly functioning.

The Goal of the meeting really depends on the project/startup, but it’s typically to ‘demo’ the product for the most important shareholders. We prefer to work directly with those shareholders from start to finish, even if it’s from a ‘chairman of the board’ oversight position, simply because we want to ship the product on time and on budget.

Deadlines

Deadlines can be very hard and very easy to set for software projects. They are easy when:

1. We have fast design iterations and feedback cycles
2. The client agrees to a ‘1.0’ after the design is finalized and we have minimal product changes
3. The client looks to the ‘burndown chart’ as their guide to when we’ll be finished
4. We do our job and have a consistent velocity each and every week.
5. We have enough time at the start of the project to hit the deadline that’s forecasted by #4.

They are hard when:

1. The client goes on vacation during the design cycle (yes this has happened multiple times)
2. The client has slow feedback and communication during the design cycle, especially when we’re looking for a simple ‘yes or no’, OR ‘yes, but change this’ type feedback.
3. The client wants changes to the product after we’ve already spent time on something else that was out of scope.
4. The client adds more features onto the 1.0, or claims that a ‘nice to have’ feature has become a ‘must-have’ and is moved into our 1.0.
5. We don’t have a consistent velocity and fail to do our job.
6. We make promises on a “launch date” that is based on ‘gut’ and not numbers. This is exacerbated when we haven’t worked with that client before, or we’re building a 1.0.

We have no problem giving ‘rough’ deadlines at the start of the project, but the client needs to understand the above. It just really sucks for all parties involved if we ‘miss’ an important deadline because the first few weeks were super slow or delayed for on feedback on a 5-month project, and we then miss the deadline by a few weeks.

Trust us, we 100% understand the importance of planning and launch, but deadlines are just something if understood how and why they’ll change, then we can all build an amazing product together.

Retrospective / Retro

Every two weeks we have an internal “Retro” where we have a fully transparent meeting to discuss the following:

1. Things that we liked, or what went well
2. Pain Points / What did not go well?
3. What are some identified problems?
4. What are some possible solutions, and what can be improved?

Take a look at one of our retros from early-on:

We will have these with our client about once a month. It’s a great open environment where we can learn of any potential pain points from the client perspective, and how we can constantly improve our process. It might seem like a waste of time for some, but we find that it allows us to move much faster overall-

Here’s a nice quote from Retrospectives.com

“Regardless of what we discover today, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.” Retrospectives.com

Burn Down / Burn Up Charts

Here’s a “Burn Up” chart that we deliver to clients if they ask for it, or if the product is already in the market (and our iteration cycles are much shorter) It shows how many points that we’ve completed over the lifetime of the project and what was accepted by the product manager.

Here’s a ‘burndown chart’ that shows how many points we have left on the project before our “Release Blocker” combined with how many points we are completing per week. So, for the above example, it looks as though we should deliver either on May 1st, or before.

There seems to be a service for almost every function of a web or mobile app, and we stumble across different and new flavors of the same type of services each and every day. There always seems to be a few ‘winners’ and then niche products that sometimes are much better than the ‘winner’ if you fit into their target persona of a persona. We could probably make this list 2x what it is, and could also recommend another 100, but the below list is our “Service Stack” that we usually role into every new product that we build

Hosting

AWS / Google Cloud / Digital Ocean

Almost all of our apps are hosted on AWS or Google Cloud. They’re scalable, dependable, and low cost.

Heroku

We use sometimes use heroku for quick staging servers and before we deploy to AWS. Heroku is extremely easy to set up, but can get quite pricey once you start getting significant traffic.

Project Management

Trello

Trello is another project management tool that we use for business and personal things. We’ve worked with a few companies that use Trello as their primary project management tool, but we don’t think it’s robust enough for large, or enterprise customers it. We use it for our sales pipeline (no need for Salesforce!) because we purposely only take on a limited amount of projects at any given time.

Pivotal Tracker

We use Pivotal for our larger projects that require ‘epics’ & more advanced project management techniques that aren’t covered through Trello.

Here are a few things to note:

1. IceBox: The icebox is where we keep ‘ideas’ and login credentials for different services we use. We’ve consulted on projects where there are 100s of stories in the icebox and backlog, so one of our first steps is to “Clean out the Icebox” This involves going through “Story” (what the
2. Cards: A card is a small block/cell that holds the User Story and all relevant information for it. You’ll see things such as who the card belongs to (who the developer is) what ‘state’ it’s in (working, finished, testing, etc) comments, and detailed explanation of the story if needed.
3. Feature / User Story: A User Story is a short, simple description of a feature told from the perspective of the person who will be using that feature. They typically follow this method…As a “type of user”, I want “some goal” so that “some reason”. You’ll potentially see 100’s of stories for your product, and we establish them in a compounding and chronological order during the initial setup.
4. Points: We assign points to each story using the Fibonacci sequence of difficulty. 0 point stories are quick fixes, 1 point stories are small, 3, 5, 8, etc. However, we limit our stories to 8 points (instead of 14+) and then just make a few smaller stories out of that large story.
5. Chore: Chores are necessary tasks that usually shouldn’t be quantifiable like stories. An example might be “Update SSL Certificates”. The reason this isn’t a story is that we’re not progressing the product forward, but just providing maintenance.
6. Bug: A bug is a bug. It’s a defect in the software that either our team or you found. We address these based on complexity and how urgent it is for the product.
7. Velocity: Velocity is a measurement of the speed of development that we are moving to. Depending on your project, this number could be anywhere from 1 – 50, with most averaging around 25-30 per week. We try and make sure this number is consistent from week to week.
8. Epic: We don’t use epics too often, but for very large projects where we need to categorize a lot of user stories into one major feature, we’ll label those stories under one epic.

App Development Communication

Google Hangouts

We’ve tried a bunch of different video conferences over the years, but Google Hangouts has won because of its flexibility and ease of use. Skype was our cowbell for a while – but asking people to download it starting to get more and more painful. We use Hangouts every day multiple times, and use the google calendar invite functionality to schedule meetings with a Google Hangout attached. Sometimes, we’ll throw hats on if it’s been one of those days, OR if a developer ships their app to the app store or launches to the public ;P

Slack

Yes, we use slack like everyone else. We were using Hipchat for a long time, but they made it a HUGE nuisance to switch between ‘teams’, whereas Slack made it a simple toggle on their menu. We think that’s the only reason Slack took off, but we digress.

We use slack for ‘quick’ communication. So things like “Hey Guys, standup in 5 minutes” or for small clarifications. Otherwise, we try to have these conversations be on Trello (so things don’t get lost in the process)

Email

We use Gmail for email, and try to keep it to a minimum. I get something like 150 emails a day, and unsubscribe as much as possible to things. Email is where proper project management goes to die, so we only use it when it makes sense.

File Sharing

Google Drive and Dropbox: While we prefer Drive because it works seamlessly within the Google App Ecosystem (Calendars, Hangouts, Email, etc) we all have Dropbox accounts.

Unless a client asks otherwise, we create a project folder for each client and we store images, invoices, wireframes, and really anything else that’s relevant to the project that we need to either reuse or look at later.

App Design Tools

Sketch

Sketch is an awesome design tool that’s won many awards from Apple (it’s Mac only) and was originally built for Web UI and UX. It has every tool a web designer needs and none of the clutter like Illustrator for Photoshop (which were not made for this reason).

There are a variety of plugins like a ‘random name generator’ that make mockups easier, and it’s rapidly improving as time goes on. We’re really excited to see where this product goes!

Figma

Figma has burst onto the scene with it’s incredibly easy to use interface & ‘limitless’ page, allowing designers to do an entire site, app, branding, & prototype in one view & one tool. It also gives perfect spacing for & asset sizes for our developers so they can deliver a perfect pixel design.

Code Repositories

Github

It allows us to save the code for all the projects we work on in the cloud, but also for multiple developers to work on a single project without sending the file back and forth to each other. Developers ‘Commit’ their code to the ‘branch’ that they’re working on, then we have another developer do a review on the code. (You can read more about this in our tech process)

Web and Mobile App Marketing:

Analytics

Firebase – Firebase once again is a great option for analytics, but is limited if you’re looking for advanced analytics funnels.

Mixpanel: Mixpanel our choice for advanced Mobile analytics. They have a robust, but easy to use suite of tool that can provide almost enough tracking data to make a Ph.D. Data Scientist happy. We particularly like their ‘people’ tool, which allows you to view exact user by user behavior, and to also create cohorts of users based on specific actions taken within the app.

Google Analytics: Google Analytics (GA) is the leader in web analytics for as long as we can remember (and I can’t think of anyone before them). GA can cover every basic tracking function of your website (visits, bounce rate, links clicks, etc) and also tells you where your traffic is coming from. There are a lot more advanced features, but we’ll let you check it out for yourself.

App Distribution, A/B Testing, and Performance Testing

Optimizely: The leader in A/B testing.

Firebase: Firebase’s A/B testing tool is amazing

Invision and Marvel: Invision has been a game-changing prototyping and distribution tool that we use on every project. It’s a simple way to upload design files, share them with clients, get direct feedback (they have a point and click comment feature) and even create a “clickable” prototype from the original untouched design.

Error Reporting

Crashlytics (Firebase!): We’ve been using Crashlytics for the past 4 years now and is more important than the grand majority of the 3rd party apps we install for clients. While our apps generally don’t crash, when they do, we want to know the exact reason why and when it happened. Crashlytics sends us an email whenever there’s a crash and also gives us information to ‘where’ in the code the crash came from. We’re looking forward to product enhancements!

Performance Monitoring

Firebase: Firebase’s product, again…

NewRelic: New Relic has gotten quite popular in the past few years, and for good reason. It allows development teams to view exactly how fast and efficiently their application is performing in the market, and provides insight into how they can optimize. We set up ‘alerts’ that hit our slack channel to let us know if the app isn’t scaling properly, or if the server is down for whatever reason.

Transactional Email

Sendgrid / SES We’ve been using Sendgrid or SES for the past four years and is typically the transactional email service we recommend to clients. Transactional emails are the type where users are going to receive them for doing a specific thing within the app. A few examples that come to mind include “Sign Up” “Confirming Sign Up” Reset Password, Signing up for a newsletter, not being active in the app for 3, 7, etc days, or if a security alert was triggered like “too many failed password attempts”.Sendgrid just makes it very easy for apps to send ‘transactional’ email and also gives data insights into what was opened, what was marked as spam, the best time to deliver, etc

Mandrill: Mandrill is a Mailchimp product that we aren’t as familiar with as Sendgrid, but have implemented before. Typically, SASS apps such as these become very similar over time, and just differentiate on price, documentation easiness, or how they get customers.

NewsLetter

MailChimp: Who doesn’t love their lovable mail delivering Monkey? Mailchimp has been around for a long time and is perfect for the 99% of businesses that just want to send out a basic newsletter to their audience. They have an OK email builder, but they also allow users to upload their own, custom-designed email template to send out. Mailchimp is free up to 2k subscribers and 12k emails a month, which is more than enough for the standard startup that’s just starting out.

Payment Processing

Stripe: Stripe has quickly moved from ‘Developer favorite” to a giant company with a huge valuation. They have a great ‘payment widgets’ that users can put on their site that handles the encryption or general development issues that would trouble junior developers but is also robust enough to handle millions of transactions a year.  Stripe is adding more functionality to cover things such as fraud prevention, company creation, and more

Braintree: Braintree is a Chicago based payment processing startup ( acquired by Paypal) that has a super-secure set of tools that makes payment processing super simple for mobile and web applications. can implement with Venmo for easy payouts (one of their brands) and are obviously part of the PayPal family so you can easily implement PayPal as well if you wish. We love their documentation and super helpful service team who rarely leave you hanging on a call.

Other 3rd party things we like

Apptentive: Great for asking for feedback in-app, Amazing at asking for a review!

NDAs

If the client asks us to sign an NDA, we typically respond with something like “Any chance we could have a quick chat without signing an NDA first?” We’ve worked on hundreds of projects, and heard countless more pitches, but have realized how similar most ideas are, or how many of the ideas pitched to us we’ve thought of ourselves in the past…

It’s incredibly difficult to execute properly on your idea, and is even harder to execute and stay passionate about it for the next 3-7 years. It’s the last part that most people forget about!

Either way, (if asked of us) we typically will sign the NDA after we hear the initial quick pitch about it. We will NOT work on competing apps, so we’d probably end the discussion if it’s too similar.

Here’s an example- If we were building an “Uber for Waffle Delivery” we wouldn’t build another “Uber for Waffle Delivery”. However, our clients do know that it’s not feasible for us to have to turn down something like a “Uber for Flower Delivery” because we’ve worked with them already. These companies are in competing markets, and most companies that are “X for Y’s” have a similar core.

To summarize, we have no problem with signing an NDA, and will never take the stance of “We never sign NDA’s” like some VCs. Rather, we’d rather have a quick chat to make sure it’s a good fit for the both of us first!

Proposals

Our proposals have taken many forms over the years and the end product has never ended up precisely as it was at the start. This is for a variety of reasons, but mostly because the product details are greatly under-discussed by the client (of course we MUST have viral sharing mechanisms and an affiliate program.

Contracts

We store contracts in Dropbox and have a series of folders for pending, current, past, and lost clients.

Twitter

We think it’s a great medium for sharing articles/news in a rapid-fire way and hasn’t been screwed up (yet) by only showing certain profile posts. We tend to ‘pin’ posts that our followers really like, we find interesting, or for big news. Follow today here! twitter.com/lakeviewlabs

Instagram

We try to use Instagram every day to highlight cool projects we’re working on, or just to document our journey. Instagram is still great because they’ve done a great job of limiting the ‘spam’ of marketers, and how they internally promote ‘real’ or ‘authentic’ quality pictures.

Facebook

Yes, we’ve all had it since the college years, but we know that most of Facebook isn’t too into pictures of a new UI of an app, or pictures of code ;P We still push content into here from time to time!

Linkedin

We haven’t been able to crack the code on Linkedin just yet. It’s not a great advertising platform, there seems to be more and more spam everyday (What’s the next number in this sequence? Upvote and I’ll quit smoking, etc) but it’s still decent for its core function: connecting and speaking with people in your network.

Our team has grown from two guys at 1871 to a healthy 6 over the years, all 100% bootstrapped.

We think the max # for a dynamic, boutique agency is around 10, so we don’t see ourselves ever getting larger than that IF we decided to cross that road and expand.

DNA

Experience

You’ll never have a Jr. developer. Never.  All of our developers and designers have at least 5 prior years of full-time experience and almost all started in high school and then continued their education in Computer Science or Design in college.  We have 4 BS & 1 MS in Computer Science, & one BS in Design!.

Skillset

Our entire team is comfortable with working on both the ‘front-end’ or ‘back-end’ of apps, but we assign everyone to their preference and skill level. We like ‘full-stack developers’ that specialize in 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 7 apps be featured in the app store. Our apps are also routinely one of the ‘top’ in their respective sub-categories “Sports Tickets” “CPA Exam Prep”, etc. We’re still on the hunt to produce 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 2020 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.  We were more carefree in years past but realized more and more that great projects only happen when both parties are great fits for each other & fully understand each other’s goals. So, we also build our own internal products for a few reasons:

1. To test or broaden our skillset: 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

SuperTailgate.com is a “Lonely Planet for Stadiums, Gameday, & Tailgating ” 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 Sports Travelers.

It’s now the #1 site for Tailgating & Gameday in the US!

Finale!

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 at contact@LakeviewLabs.io