Non Technical Overviews of Technical Things: Flask

At Oak City Labs we develop using a particular stack of technologies we are not only comfortable with, but believe to be the most effective tools in solving whatever challenges come our way. Too often when a developer says “We use X framework or Y library”, it sounds like utter gibberish and has no real meaning to non-technical people. This disconnect is the inspiration for my blog series: Non Technical Overviews of Technical Things.

In this post, I will cover Flask, the web framework we use. You can think of a web framework as a set of building blocks that developers use to write a web application. It’s important to note that in this article when I say “web framework,” I’m talking about a web server framework. In other words, Flask lives on a server in the cloud rather than running on a user’s computer. Flask is an "unopinionated micro web framework" written in Python.

Let’s break that down:


Why “micro”? Because instead of being an all-in-one swiss army knife style solution, Flask is an add-as-you-go barebones solution from the start. This low barrier to entry allows developers who want to build a small program or a quick prototype to just download and get going with a few simple lines of code. According to the Flask docs, “The ‘micro’ in microframework means Flask aims to keep the core simple but extensible.”


Why “unopinionated”? Again, the Flask docs explain it best, “Flask won’t make many decisions for you, such as what database to use. Those decisions that it does make … are easy to change. Everything else is up to you, so that Flask can be everything you need and nothing you don’t.”

Web Framework

A web application could be anything from a website to a mobile app to an online document editor to an email program. In programming, a framework is a tool that aims to prevent developers from having to rewrite code each time they want to accomplish a task. Thus, web frameworks fill the role of facilitator and middleman by allowing developers to quickly create web services, resources and APIs that people can interact with through user-facing programs like web browsers and mobile apps.

Okay, that’s cool and all, but what does a web framework mean to me, an average user?

A lot of tasks in web development are very repetitive. One example is as simple as a user visiting a webpage. Let’s use Google as our example. Let’s say you open up your favorite web browser, type “” and hit enter. You see something like this:

In this scenario, the web browser is in charge of:

  • Displaying what you see, from the search box to the Google logo

  • Allowing you to interact with the page

And the web framework is in charge of:

  • Providing your web browser the code for the page, the images, and any scripts that run on the page.

  • Performing any searches you enter

  • Logging you into your Google account and ensuring you stay logged in

Why do we use Flask?

As a services company, we often begin working with clients by building small prototypes to test the viability of certain ideas for them. As such, we have found that choosing tools that allow us to easily and quickly build prototypes for potential long-term projects is essential to success.


In the software world, prototypes are often scrapped once a project is given the green light. With Flask, we can quickly build up a prototype and just as easily build on top of it as we go. Think of Flask as a kit of legos where the main building block has nodes on every side to be built on top of. You can customize it any way you want, work with other technologies any way you want, and it doesn’t tell you that you should do anything a certain way.


While Flask is small in size, it is developed in a way that allows it to scale incredibly well. The Flask docs have an entire chapter on “becoming big.” Even Pinterest uses Flask for their API! For CurEat, we built the original prototype using Flask, and now in release, with thousands of users and about a dozen pieces of technology all working together, Flask is still working like a well-oiled machine, showing no signs of slowing down.

Additionally, the small overall size of Flask means there are less places for security vulnerabilities to occur. If there ever were to be a vulnerability in the code discovered, Flask’s large, active open source community would handle it swiftly and promptly release an update.

Here’s a Quora post showing some large web applications that use Flask.


We really like Python. It is a well-documented and incredibly popular programming language being used increasingly for web server development due to its modularity and ease of use. The other popular web server programming languages are PHP, Ruby, and Java. PHP and Java show their age and are well known for not being quick prototyping languages. Sinatra is the Ruby equivalent to Flask. We find Python to be an easier programming language to work with overall, and more developers are familiar with it, so there is typically more out there in terms of 3rd party libraries and documentation.


This is perhaps the most important point of all. As an app development shop, we have to always be ready to adapt to rapidly changing requirements. Flask allows us to easily change direction without having to backtrack and lose valuable time. Flask also allows us to change the type of tools we use alongside it without having to change the logic itself. For instance, we could go from using a simple file for data storage during prototyping to a fully redundant PostgresSQL database in production without any change in logic. This ability to change at a moment’s notice is very helpful when we are deciding how we want to structure a project.


  • Flask is a web server framework, which is a crucial piece of any app or website that uses the internet.
  • Flask helps us manage all the different pieces that go into creating our mobile and web apps.

  • We like Flask because it is small, flexible, durable, and allows for easy prototyping.

This was the first part of a series of non-technical overviews of technical things. Stay tuned for more!

Replacing the App Delegate for Unit Tests on the Mac

TL;DR — Using an empty app delegate for unit testing is great for iOS developers. With a little modification, Mac developers can do the same.

App Delegate — Not in Charge Anymore

At Oak City Labs, we’re big believers in the power of unit testing which is vital to the health and reliability of our build automation process. Jon Reid runs a great blog called Quality Coding, focusing on Test Driven Development (aka TDD) and unit testing. Jon’s blog is one of our secret weapons for keeping up with new ideas and techniques in testing.  

A few months ago, I read Jon’s article, “How to Easily Switch Your App Delegate for Testing”. It’s a quick read detailing a neat trick for speeding up execution of your unit tests. The gist is that you switch UIAppDelegate classes at startup, before the bulk of your app has bootstrapped. By switching to a UIAppDelegate just for testing, which does absolutely nothing, you bypass the app’s startup routine that slows down test execution. Faster tests mean less time waiting and less pain associated with testing. 🎉

There’s also another benefit that Jon doesn’t really mention. Because you skip the normal startup routine, the only code executed must be called by your test. Say I’m writing a test for my DataController without using this technique. The test is failing and I drop a breakpoint in the initialization routine. When I run the test, the the debugger stops at the breakpoint twice — once because the app is bootstrapping itself and once for the unit test that creates its own DataController. Now there are two DataController instances running around. Comedy hijinks ensue!

On the other hand, if you switch to an empty UIAppDelegate for testing, we can eliminate the bootstrap altogether, meaning only one instance of DataController is created and that’s part of our unit test. No more confusion about whether an object in the system is under test. By dynamically choosing a testing UIAppDelegate, our tests run faster, there is less confusion and, as Jon points out, it becomes easy to test our production UIAppDelegate too.


Back to the Mac

Hopefully you’re convinced at this point that choosing an UIAppDelegate at runtime is a Very Good Idea. Setting all this up for an iOS project is thoroughly discussed in the original article, including variants for Objective-C and both Swift 2 and 3. At Oak City Labs, we write Mac Apps too, so how does this translate from mobile to desktop?

For reference, here’s an implementation of main.swift I’m using in an iOS Swift 2 project.

This is pretty straightforward, since `UIApplicationMain` takes the name of the UIAppDelegate class as one of it’s parameters. Unfortunately, when we move to the Mac, that’s not how `NSApplicationMain` works. Showing it’s C roots, `NSApplicationMain` just takes `argc` and `argv`. So, in order to make this work on the desktop, we need to do a little extra jiggery pokery.

Running normally, we just call NSApplicationMain like always. Running in unit test mode, we need to manually create our empty NSAppDelegate and explicitly set it as the delegate property of the global shared app instance. Then we’re ready to kick off the run loop with `[NSApp run]`.  

Side note — I started writing this in Swift 3 since the rest of the project is Swift 3, but I’m still new to Swift 3 and I couldn’t manage to get the instantiation from a class name bit working.  Luckily, I realized I could still write my `main()` routine in trusty, old Objective-C and it would play nicely with my type-safe Swift application.

Just for reference, here’s my TestingAppDelegate class. Like school on Saturday, this class is empty.

We want unit tests to provide fast feedback, and clear feedback. Using the empty TestingAppDelegate approach makes our testing better at both. Now, with a little runtime hocus-pocus, we can employ delegate switching on the Mac as well as iOS.

How to Find Total Addressable Market Numbers for Free

Many people ask me if their app idea is a good one. They are often searching for validation of the idea before spending a ton of money building it. If it’s a market that I’m familiar with I can give a gut answer. More often than not though, I’ll start asking questions about market size and opportunity. In a few weeks, we’ll be hosting a free workshop on not only the questions to ask, but how to do this research and why it’s important. Today I’m sharing just a snippet of some of the content we’ll cover and why it’s incredibly important to businesses and entrepreneurs.

To begin, one of the most important pieces of data to find is the Total Addressable Market (TAM). The total addressable market is the size of the market that represents the actual revenue opportunity for your company. Most investors, whether external or internal, will want to understand the size of the TAM. It’s also part of a value proposition statement. And, hint: it’s most likely NOT the first really big number you find.

Let’s say you have an idea to build a mobile app for contractors to do project estimates on the fly. First, we go to our trusty and free market research tool, Google. We do a search for “contractor estimate tool market”. Not much comes up because it’s narrowly defined, so we widen the search to “construction software market”. Now we’re getting somewhere. Result #4 is a link to a press release that highlights a new market research report covering the “"Global Construction Management Software Market 2016-2020”. This is really close to what we need. However, most press releases aren’t great for actual numbers unless you’re willing to pay for the report (which can help greatly depending on the business case you need to make). This press release is fantastic for other items, like a list of key competitors and CAGR for market growth (how fast the market is growing). We can use a company from the list, Procore, and do a Google search for “Procore market share”. There are several interesting articles in the news about Procore reaching a valuation of $500M in December 2015 and another company being acquired for $600M by Oracle. Another one of the results shows Procore with a 1.5% market share. That’s a pretty nice looking opportunity based on the valuation and current market share. To really determine the legitimacy of the market data would take a few days of research versus the 15 minutes spent for this blog post.

We can already see some patterns emerging from just the one press release, but what about our original idea of a contractor estimation tool? Procore addresses larger companies, which makes sense for the numbers that we’re finding. For our app idea, we want to focus on small to medium sized contractors. We’re back to square one, aren’t we? But all is not lost, we can use that report and the other information for future reference. It can also give us ideas for key search terms for future research.

Maybe we should back all the way up, because sometimes you have to go backward to move forward. How many construction contractors are there in the US? Literally, put that whole phrase in Google. The first hit takes us to a trade organization, AGC of America. Trade organizations and conferences are great references for high-level market data. AGC sites a statistic of 650,000 employers with 6 million employees. That could be a lot of customers! Even more interesting, there’s a link at the bottom about construction spending which gives us numbers about actual spend. A mistake people make often is using the total industry spend as a representation of market size. What we really need to look for is “construction spend on software,” and then construction spend on software estimation tools. Using “construction spend on software” takes us to a Construction Software Buyer Report. It’s a little dated but we can work with it. The key stat is that “prospective buyers are willing to spend $7,766 for the purchase of new construction software.” And look! The top reason for evaluating new software is to “improve the accuracy of estimates.”

Screen Shot 2017-04-05 at 1.01.41 PM.png

And the entire article is a fantastic source for more information. It includes a link to another article about a downward trend in spending which we should keep in mind. Most importantly, it includes an article link to exactly what we’re looking for, a research report conducted by JBKnowledge in conjunction with two other associations and a university. This should contain some good data and it does. They have over 2,600 survey respondents covering a wide range of budgets and sales volumes. It also has an interesting graphic depicting the resistance to use estimation tools in the cloud:

And one that offers more insight and potential opportunity in the market:

To sum up where we are, we’ve found a good list of competitors and we’ve started to identify the key search terms in order to find good market data. It might seem like we jumped all over the place but that is the reality of doing market research on a budget. It takes a lot of reading articles and a decent about of time. Good market research is going to take time and effort. With just 15 minutes of hunting, we found a really good, quality report on the market. Next steps for finding actual Total Addressable Market:

  1. Dig deep into the list of competitors and start to compare features. In fact, a feature comparison spreadsheet or chart is a great tool to use. While researching competitors, make note if one is a public company. If they are, reading through the publicly available investor reports like a 10-K or quarterly report can produce very insightful information about revenue and market growth.

  2. Continue searching via Google with various phrases pulled from reports and the industry. Some might include:

    • Number of construction contractors in the US

    • Average revenue or budget per contractor in the US

      If you can find the first two and the percent of budget spent on software then you can make some assumptions about numbers. Let’s say most contractors spend 1% of their budget on software.

      # of contractors in the US * budget per contractor = total budget available.

      Then: Total budget * .01 = estimated spend on software.

    • Based on one report we found, we know that 71.1% of contractors use a software tool (versus a spreadsheet) for estimating. We can make a best guess that 71.1% of total contractors in the US use software for estimating. Which might be a little high given the study group. But let’s go with it for now until we find supporting or competing numbers. That same report from JBKnowledge also highlighted most contractors were not very happy with the solutions, so perhaps there’s opportunity to improve?

  3. Continue hunting for and looking on trade association websites for data.

  4. If all those numbers still sound good and we see a pattern developing, then we should move on to a very important next step: talk to people. As many as possible, in what is formally known as a Voice of the Customer survey.

  5. This is all just the tip of the iceberg, to learn more and continue the discussion, we’d love to invite you to our FREE workshop on market research. To find out more and to register visit this link. We hope to see you soon!