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.

Hey there!

Welcome back to my series of non technical overviews of technical things. This week I’ll be discussing the basics of how a website is born. Well, you see, when a mommy website and a daddy website love each other very much…

Just kidding! Modern websites are composed of the following three components:

  • HTML (HyperText Markup Language) - Content and Structure

  • CSS (Cascading Style Sheets) - Appearance

  • JS (Javascript) - Functionality

If you have heard these terms before but have no idea what they mean or how they affect your website, have no fear! Soon you will have a grasp on the basics of how websites are made so that you can appear hip and knowledgeable to all your colleagues.


House Analogy

Take this house:


Pretty swanky house, right?

Right. Now, let’s divide this house into its structural, aesthetic, and functional components.

  • Structure and Content - Structurally we have the foundation the house is laid on, the walls, floors, ceilings, supports, frames, etc. For content, we have the potted plants, the couches, chairs, tables, TVs, beds, appliances, nerf guns, and anything else that gets placed inside the house.

  • Aesthetic - For appearance, we think of the way the house looks. This component spans everything from the type of wood on the floor to the color of the walls to the way the furniture is arranged. Anything that changes the way the existing pieces of the house look is lumped into this category. This includes changing the width and height of structural elements, as well as how much space exists between structural components like the couches and TV.

  • Functionality - Think electrical, gas, water, internet. Anything that makes the house work like a house should as compared to a hollow, functionless shell.

Structurally, a few rooms in our house might look something like this html file:

Aesthetically, we can add some color, borders, and widths of certain things like in this css file:

Functionally, we can specify interactions with elements from the html in a js file:

Now, this code is far from complete, but I want to highlight a few things about it by using the door as an example:

  • An element gets defined in the html file:

  • A style gets defined in css so that anytime that element appears in the html file, it has the same style:
  • Finally, functionality for the door gets defined in the js file we saw above:

The website a user sees is essentially the structural, aesthetic, and functional components working together to create an experience.

Finally, I want to give a quick real-world example of these three components.

Navigate to Google in Google Chrome browser:


Right click, hit ‘Inspect’:


The developer console will open at the bottom of your browser


Search for and highlight the line that starts with <body ……>


On the right side, you’ll see the following:

Highlight the #fff as seen above, change it to #000 as seen below, and hit enter:

Boom! Google is now black. You just used hex codes and css to change the color of Google!

Now, you might be wondering whether other people can see the changes you made or not. The quick answer is nope, nobody else can see what you did. Why? Because when you access a website, the HTML, CSS, and JS files for that website get copied from their computer to yours. Any changes you make to the files that were downloaded to be viewed in your web browser are ONLY on your computer. You can make Google look black, white, rainbow-colored, filled with unicorns, or even covered with custom poetry, but in the end only you can see your changes! And if you refresh your page, all your custom changes disappear and the files look the exact same as the ones from the server.

I bet you’re wondering now how the files from the website you’re accessing get to your computer in the first place. The quick answer is websites on the internet are all hosted on servers. Server is a fancy word for a computer that host publicly accessible information via the internet. Last time I described the web server framework we use at Oak City called Flask. Flask helps us manage all the different pieces that go into creating our mobile and web apps, but in this instance, it is largely responsible for allowing the HTML, CSS, and JS files of our websites to be downloaded and accessed by users.

What We Learned

  • Websites are comprised of three components: structural, aesthetic, and functional
  • These components, respectively, are called HTML, CSS and JS

  • These files are copied from servers to users’ computers when websites are accessed.

The internet is an exciting place where you can watch cat videos, promote your business, or brag about your sock collection. Or all three, at the same time. You could make a website with a video of your business that sells hand-knitted cat socks. That’s a free business idea for you right there. Don’t forget about me when you’re famous!

I hope you found this post informative. Fun fact, building websites is one of our specialties here at Oak City Labs! Drop us a line if you’re interested in chatting about having a website made for you or your business.

Shoestring Market Research

Two weeks ago we hosted a workshop discussing market research and validation. We shared several methods, tools and resources to use while researching a market opportunity. Most importantly, we covered why you should do research before building anything. Today’s post summarizes a few of those items and will give you a starting point into tackling your own market research.

Value Proposition

The hardest part of research, or anything really, is simply getting started. I like to begin with the goal of writing a value proposition. Fortunately, I spent plenty of time during the NC State TEC program working through value propositions, particularly one based on Geoff Moore’s Crossing the Chasm. I’ve since used the same value proposition with product teams, clients and our own internal projects. In order to “cross the chasm” and avoid certain death, you need a plan, a position and understanding of your market.

A well-researched value proposition will help you think purposefully about the business or product you are about to build. The structure to follow is:

For (target customer)
who (need or opportunity)
the (product/service name)
is a (product/service category)
that (statement of benefit)

Unlike (primary competitive alternative)
our product (statement of primary differentiation)
which leads to (economic impact)

If you break down each section, it walks through market size, problems and needs. It also covers competitors and your own unique differentiators. Using the value proposition as a guide, you begin with finding market opportunity or size in dollars. I primarily use Google search for finding reports or charts that show market size. As an example, we’ll research the construction software market. Here are sample search terms I might use:

construction software spend 2016
construction industry spend on software
construction software market share
construction software market size

It’s a good idea to also look at Google Images and different file types when using these terms. The data you’re after may be in an image or on a report. For file types, add “filetype:pdf” or “filetype:ppt” to the end and you might even find a report from another company that has surveyed the industry of interest.

Often times I’ll take a stab at writing the value proposition without real numbers and then fill them in later. Your value proposition will likely get re-written multiple times during the course of research and feedback.

Voice of the Customer

Outside of Google searches, the most important tool in your market research arsenal will be talking to people. The formal research method is called Voice of the Customer. It includes in-depth surveys, discussions and tracking of data from real human beings. Most small businesses might do a light version of Voice of the Customer in 4 steps.

  1. Create a contact list of people, including potential customers

  2. Create a survey to use as a guide for interviewing people

  3. Call and talk to people

  4. Analyze the survey data and look for patterns

The survey itself should have very open ended questions. You do NOT want to lead the interviewee. Here are some examples:

  1. What’s the most difficult part of your job?

  2. What are your top 3 challenges right now?

  3. If you could automate any part of your job, something that you find yourself doing over and over, what would it be?

  4. Is there anyone else that I should talk to?

Set a goal for the number of people you’ll contact. One hundred is a good start, but 200+ is even better. If you have a team and can talk to 500, you’ll have more data to support any conclusions. It’s also good to ensure the surveys are stored somewhere for review. It’s really easy to write down notes and then lose them later.

In every product or feature I’ve seen built, the most successful ones are supported by in-depth discussions had with real human beings. In-person conversations can also lead you to other resources and connections. For example, trade associations or conferences may not show up at the top of your Google searches. As an added bonus, some of the people you interview may become the first champions of your product.

Other Resources

Finally, a list of all the resources I’ve used in the past for research:

  • Google

  • Google Trends

  • Voice of the customer

  • Social media - Twitter, LinkedIn, Quora

  • Trade associations

  • Paid reports (IBIS, Gartner)

  • Networking events and conferences

  • App stores and reviews (Google Play and iTunes)

  • Digital surveys by using Typeform or SurveyMonkey

  • Annual reports, earnings calls

  • Job postings

  • University libraries and public libraries. Most public universities, like NC State, have resources available for alumni and community members.

There are so many resources available for market research on a budget. If you’re feeling overwhelmed and need an actionable market research plan, shoot me a note - I’d love to hear from you!

Agile 101: What It Is and Why We Use It

At Oak City Labs, we’re an "agile shop" meaning we practice a project management methodology known as Agile, the specifics of which are interwoven throughout our relationship with each client. Most of our clients are entrepreneurs and organizations that are coming to us with a brand new app idea and don’t always have a background with software development projects. The words Waterfall or Agile, Sprint or Backlog often need explanation.

Waterfall vs. Agile: What’s the Difference?



The waterfall methodology is exactly as sounds: linear. One phase in the process happens after another after another until the project concludes. From the onset of the project, each phase informs the next and must be completed before the project can proceed. If we were developing an app using this methodology, the project would begin with a set of requirements, followed by a design phase, then development, then testing and finally deployment. The client sees the working app once all development and internal debugging has been completed. Following their review, their bugs are fixed, the app would be released and maintenance begins! Hooray!

The catch? What if while reviewing that app for the first time you see that a feature isn’t meeting a user goal the way you thought it would and you know you need to make a big change to fix that? Since development and initial debugging are already complete, major changes aren’t so easy. Going back to the drawing board would likely require a change order, extra budget and a timeline delay. Oof!



The agile methodology is markedly different. The word agile is defined in the dictionary as "being able to move quickly and easily." Nimble is listed as a synonym. Sounds about right, for projects that use an agile methodology are just that: nimble.

An app developed using the agile methodology would begin with a discovery phase, in which the client would work with us to not only lay out the strategy of the app (competitive research, user interviews, revenue strategies, etc.), but also to define a list of requirements and needs for the project backlog. These requirements are ordered by priority within the backlog. As development begins the team works through the backlog in that priority order during a series of weekly sprints. Each sprint begins with a planning session to review the backlog and determine what items will be tackled during the week ahead. As soon as a working version of the app is ready, even if not fully complete, we begin demoing the app with our clients during weekly check-in calls. And as soon as a functional app is ready, we provision our clients’ devices with beta builds so they can begin testing themselves, all the while development sprints continue. With each sprint, we add more features from the backlog and are able to adjust requirements and features as needed from feedback received from the client. This iterative approach not only enables the client to be involved earlier on, but also allows for feedback and adjustments to the requirements (aka backlog) as the project progresses without upsetting the apple cart.

So What’s Better for Your Project?

Both methodologies have their own merits, and as a PM, I’ve managed each. At Oak City Labs, we operate using the agile methodology because we believe by prioritizing features and getting in-progress builds in front of our clients' eyes early on, agile leads to a better end-product for our clients.