In a past life, I managed a restaurant. The first two weeks were brutal.
Instead of hopping into Profit and Labor reports, or supply-chain breakdowns, the restaurant owner plopped me smackdab in the kitchen. And I mean, smackdab in the kitchen.
I worked grueling 10-hour days with feet begging for a break. I experienced life as a dishwasher, as a prep cook, and as a line cook. I chopped until my hands blistered, freaked out over 20 tickets piling up, and was soaked in more dish sprays than I cared to remember.
Because the restaurant owner knew I needed context.
I didn’t have to be a line cook to manage the restaurant, but I had to know enough to get around.
Why a similar approach benefits non-technical founders
You don’t have to be technical to found a tech startup. In fact, non-technical founders can establish and run incredible tech companies. (We know, because we’ve helped some do it.)
But while non-technical founders don’t have to have a BA in computer science, they should know enough to follow what’s going on. The best non-technical founders aren’t developers, but ask really good questions and hold employees accountable.
This post provides the high level concepts and basic vocabulary you need to be dangerous in the tech realm--including discovery and design phases with an outsourced development team.
We recommend you view each term as a trailhead; it’s possible to go much further, and branch off in many directions, from our high-level starting points.
We may not be able to throw you in the kitchen for a week, but we can equip you to walk into it!
Psssst: This post is meant to be an ongoing reference guide. It’s rather long, so go ahead and add it to your bookmarks, for when you need to reference it later.
Table of Contents
Part 1: Discovery
- Roadmapping session
- Scope of work
- Target audience
- Business model
- Unique value proposition
- Minimum viable product
Part 2: Design
- UI design
- UX design
- Style guide
Part 3: Architecture
- Database models
- Back-end and front-end
Part 4: Development
- The cloud
- Programming language
- Web app
- Native app
- Hyrbid app
- Open source code
- Version Control
Part 5: Maintenance
- Product management
- Quality assurance
Part 6: Security
Part 1: Discovery
Discovery is a fancy agency word that means “figuring out what you need and why.” For us, it also means partnering with you to nail down important information about how your startup operates. We don’t just care about your product; we care about your business, what you want to build, and who you want to build it for.
This is a paid meeting where we learn your business inside and out, then craft a plan. We determine what steps take you from idea to in-your-hand product. The plan (your roadmap) will include rough UX designs, a detailed budget and timeline, and some action items you’ll want to complete before launching your minimum viable product, also known as an MVP (defined below).
Scope of work (SOW)
An in-depth document that outlines what needs to happen and when. SOWs make sure everyone agrees on the end goal, process, and assignments. We call our version of a SOW a Roadmap (check out an example). It includes clearly stated goals, an implementation plan, cost and timeline, and other project-specific details.
Your product delivers benefits to customers. Features are the tangible, technical way you deliver those benefits. Google docs, for example, provides collaboration. That’s a benefit. Commenting and suggested edits are both features; they deliver the collaboration benefit. Features are similar to user stories.
How you plan to profit. At your early stage, this is usually a set of hypotheses--how you think you can create your product, market it, generate revenue, and turn a profit.
Unique value proposition
The way that you, and only you, deliver a specific value to a specific audience. If you have competitors, this helps customers understand why you’re the best choice for them. If you’re in a new market, this helps customers understand why you exist and are worth paying attention to.
Entrepreneurs generally build a prototype for one of two reasons. Either they want to test a technical concept, or they want intrigue a group of people, such as customers or investors. While a prototype isn’t as fully functional as an MVP (below), it’s useful for pre-sales, raising investment, generating a buzz, and testing small functionalities.
Minimum Viable Product (MVP)
For Krit, an MVP is a complete story; it has a clear purpose and just the right set of features to solve a user’s problem all the way through. It's not minimum releasable garbage that’s been hacked together and barely functions. Rather, it's an insanely valuable package of one or two core functionalities that lets you start small, gather feedback, and build up to exactly what customers want.
Part 2: Design
Design is about (a) figuring how a product should work and then (b) how the workings should look. It’s where decisions on color, typography (the art of using fonts and typefaces), and other aesthetics happen. But more importantly, design is where you consider how a customer moves through the product and learns to work with it.
At Krit, design isn’t totally separate from development. Our design team understands programming, and we ensure designs make sense for development.
The simplest and fastest form of design. Sketches are quick, unpolished drawings that visualize an idea. You’ll usually see them on a whiteboard or in a notebook.
More detailed that sketches, but less detailed than mockups. Wireframes are similar to blueprints for a house. Blueprints don’t tell you what color the bathroom walls will be, or whether kitchen hardware will be copper or brushed nickel. But they do show how many rooms there are, how you can move through a house, and where key appliances will go. Likewise, wireframes ignore color, fonts, and other visual details. Instead, they focus on layout, information placement, and where important pieces should be (this is sometimes referred to as visual hierarchy).
What most folks think of when they hear the word “design.” Mockups are very detailed displays that show, as closely as possible, what the app will look like once it’s developed. Mockups include the exact colors, fonts, gradients, and other small visual elements you’ll see in the final product.
User Interface Design (UI Design)
UI design focuses on how your application looks. This means focusing on typography, style, colors, and animations. A designer focused on UI will ask questions such as: Is there enough padding between elements? Is there a visual balance?
UI design is about making your app look beautiful and engaging.
User Experience Design (UX Design)
UX design focuses on how easy a product is to use, and how it makes the user feel. A designer focused on UX will ask questions such as: Is the information laid out in a way that makes sense? Does the product react to a user's input the way they expect it to? Is interface helping users solve their problem or getting in their way?
UX design can also encompass copywriting, customer support, automatic emails, and much more.
A sandbox is a super nifty way to speed up development. At Krit, this is when we create a single page in the application that contains all the design elements, built out in code (minus any functionality). This is a huge help to the development team. Instead of creating these elements from scratch and worrying about their appearance, developers can simply pull the sandbox pieces as they need them.
Your brand is how customers experience and recognize your company. It includes layers of what, how, and why (check out the “golden circle” by Simon Sinek below).
The WHAT layer includes your logo, colors, and product. The HOW layer includes your approach, technology, and/or process. And the WHY layer is your mission, values, and the reason you think the ridiculously hard journey of building a startup is worth it.
Note: Branding, or brand marketing, is about creating and controlling customers’ perceptions of the what, how, and why.
The visual “house rules” for your product and/or brand. A designer creates this guide, and it includes directions on how to use specific colors, fonts, patterns, icons, and other visual elements. The guide helps ensure your app looks cohesive both now and later on, as you change and improve it.
Part 3: Architecture
Your application will have a lot of pieces. Architecture is about planning out how those pieces will work together. It deals with databases, tables, and how everything communicates. A development team will determine an app’s architecture, before they begin building it.
Think of a database as a warehouse that stores all your application’s data. There are different types of databases, and each type organizes information in a different way.
A SQL database is like a series of excel spreadsheets; each table in the database would be one sheet. A NoSQL database (such as a MongoDB) is more like a Word Document. It’s more flexible, but it can make managing relationships between data more challenging.
A database model outlines how a database stores and shares information. There are many different models, each with their own advantages and disadvantages. The most popular type of database model is something called the relational model. Its basic unit is the table, where information is stored in columns and rows.
Back-end & front-end
Every app consists of some sort of front-end and back-end. In a car, the back-end would be the engine and the front-end would be the dashboard and the gas pedals. The dashboard (front-end) takes user input and translates it to the engine (back-end) to move the car forward. In an app, the front-end delivers user input to the back-end, which stores and retrieves data from the database. Back-end development focuses more on data, algorithms, and performance. Front-end development blends in more aspects of design.
Application Programming Interface (API)
An API is how the back-end and the front-end of apps communicate. It’s also how your app communicates with other technology. You can think of APIs as messengers; they relay instructions and responses between two pieces of software.
Note: When building an app, it’s important you create API standards. That way, developers across your team, and other teams, know what to expect.
Part 4: Development
Software development refers to a whole bunch of technical activities that go into building and maintaining a piece of software. It involves all the coding, languages, frameworks, testing, and collaborative processes that developers use to build the final product.
A server is a computer set up to serve files or data. (See? Sometimes tech nomenclature does makes sense.) Any time you access a website, you are making a request to a server over the internet. The server processes your request and “serves up” something--hopefully, the website you want--in response. Servers are almost always connected to the internet.
Note: In the past developers had to physically install and setup servers at data centers. In recent years, servers have become cheaper and easier to set up remotely, thanks to tools like AWS, which stands for Amazon Web Services. Tools like AWS, Google Cloud Platform, and Microsoft Azure make it possible to setup a server in minutes from your computer. This has lead to the rise in “the cloud.”
"The Cloud" sounds nebulous, but it’s just a series of servers connected to the internet. We recommend limiting your use of the phrase "the cloud" around developers. Once or twice a year is ideal.
There are many different programming languages and each language has a different set of rules, philosophies, and advantages. To further complicate things, some devices or applications only support certain programming languages.
The good news is, the fundamentals of many programming languages are the same, even if the nitty-gritty rules differ.
Note1: Good developers should be able to pick up new languages, and most know at least a few. This means you should hire for overall skill and not a particular language. Just make sure you give a developer learning a new language time to adjust.
The most common programming languages among professional developers, according to the 2018 Stack Overflow user survey. [ https://insights.stackoverflow.com/survey/2018/#most-popular-technologies ]
Each programming framework is a toolbox for programmers. Different frameworks are based on different philosophies and supply different tools. Programmers will select a framework based on what they’re trying to build and what tools they need to reach the end product.
The most common frameworks among professional developers, according to the 2018 Stack Overflow user survey. [ https://insights.stackoverflow.com/survey/2018/#most-popular-technologies ]
A web app is an application that's hosted on the web, rather than downloaded on your phone or computer.
Note: What type of app you need depends on what kind of problem you’re trying to solve.
Native app/mobile app
A native app is a mobile app that's written in the native programming language of a mobile device. On iOS (iphones) this is Objective-C or Swift. On Android this is Java. Each native platform has its own paradigms and set of common elements. Native apps are strong in the performance realm. They also allow you to deliver the kind of experience users expect for their particular platform.
A hybrid app is a mobile app that’s built using web technologies, and then compiled into two mobile apps. It’s not purely native; neither is it entirely web-based. Hybrid apps have one big advantage: they only have one code base. This means they take less time to develop and are easier to maintain. The tradeoff? Quality, especially when it comes to performance.
Open source code
Knowledge sharing is one of the greatest things about software development. When a developer builds a new tool, they will often share it with the world. They do this by opening up the source code--the inner workings of the tool--to the public. When a developer does this, learning accelerates and the entire industry gets stronger.
Note: If you're selling a technical product, open source code can also double as marketing or recruiting.
When developers initially write code, they keep it on their computer--only they can access and edit it. This is similar to if you created a Microsoft Word document on your desktop. Once developers clean up and polish code, they move it somewhere that the app, or other people, can access. The activities that move code from a developer’s computer to a more available location are deployment.
DevOps refers to development operations, a process for managing changes to software. It affects developer workflows, testing code, deploying code, and fixing code. Good DevOps optimizes how quickly and safely a team deploy updates to your application. DevOps can range from simple and manual, to complex and completely automated.
Version control is a system for managing and storing updates made to a code base. It allows you to track changes to your code, revert back to a previous version if an update introduces an error, and enable multiple developers to work on the same thing.
A very simple example of this is Google doc’s revision history.
Note: The most common version control system is git, and the most common git application is Github. In git, a code base is called a repository. Updates to a repository are called commits. There are lots more terms specific to git, but those are the basics. Your app needs to be on version control.
Test-Driven Development (TDD)
A practice where developers write tests first and then write the rest of their code to pass the tests. For example, writing a test for a given piece of functionality (e.g. filling out a sign-up form creates a user in the database) and then writing the actual code to make the test pass.
Good tests help developers avoid unnecessary bugs and make improvements with confidence. Some of the main types of tests include: automated tests, manual tests, stress tests.
Part 5: Maintenance
No app (or any other form of tech, really) is a build-it-and-forget it kind of thing. Maintenance is about keeping the app in tip-top shape and making critical improvements as customers use it.
Agile is an iterative approach to developing software. It used to be that developers would work on code for months and then ship large updates at one time. This is called the waterfall approach. An agile approach presents a fast-paced alternative. It emphasizes shipping small changes over short intervals (called “sprints”) for continuous improvement.
Note: There are several different methodologies that apply the Agile approach. The SCRUM framework is very popular in tech.
Product management means overseeing the success of a product. It involves high-level strategy, vision, problem-solving, prioritization, and getting things done quickly. While the product is the focal point of all this, good product management takes everything in context. Business goals, audience, marketing, brand, technical costs...these all factor into strategic product decisions.
Quality assurance (usually shortened to just “QA”) focuses on making sure products meet requirements and expectations. The bedrock of QA is testing. A QA professional, or developer performing QA, can employ many types of tests—automated tests, manual tests, stress tests—to assess a product’s quality.
Documentation explains how code works and why certain pieces of code exist. Documentation can be inside the code, in the form of comments, or outside the code in some kind of text file. Poor documentation makes maintenance extremely difficult. If developers leave no instructions, or confusing instructions, co-workers and/or future replacements will have a hard time improving and fixing existing software. (If you’re ever tried to follow a recipe with missing ingredients and steps, you get the idea.)
Documentation helps explain why and how specific code functions. It’s important, because developers won’t always be on-hand to explain their work.
As a general term, a “bug” is something that causes software to break or behave in an odd way. A bug can be software related or attributed to some other factor. Software-related bugs include syntax errors, architectural mistakes, runtime errors, and server failures. Some bugs that are not technically bugs include problems like usability issues and requirements issues.
Part 6: Security
While it’s listed as “Part 6,” security isn’t an afterthought; we’re big on protecting our software from threats and danger. As hackers grow increasingly skilled, we have to grow increasingly clever and forward-thinking. There are many, many more terms that could go in this section, but these definitions will get you started.
When a developer encrypts something, they translate information that’s normally readable into scrambled code. If anyone wants to access that information, they’ll need a “key” to make sense of the encryption. This minimizes the chances that anyone, besides the recipient, gains access to important information. Some apps, such as WhatsApp, automatically encrypt and decrypt messages sent between users.
Note: Encryption is sometimes confused with hashing. Whereas encrypted information can be deciphered using a key (it’s a two-way transformation), hashed information is irreversibly altered (it’s a one-way transformation). You should always hash passwords.
A word, phrase, or piece of information that allows you to gain access to something. The strongest passwords are difficult for both humans and computers to guess; they’re unique, long, and contain numbers, letters, and symbols. The worst passwords are common, such as password1234 or welcome or football.
Note: Most people reuse short, memorable passwords for many different accounts. While this is understandable—how many of us can remember 20 different strings of letters and numbers?—it’s also dangerous. Password managers, such as 1Password, let you create, store, and easily access unique passwords for all your accounts.
Two-factor authentication (2fa)
2fa is one type of multi-factor authentication. It uses two different factors to confirm someone’s identity when they’re trying to access information. For many apps, this means users must enter (1) their password and (2) an expiring code sent to their phone. Because traditional verification requires only one factor (e.g. a password) to verify someone, 2fa is more secure.
Note: Seen a load of pop-ups about cookies lately? That’s because the European Union implemented new data regulations in 2018. Any website that serves European customers must asks users to consent to cookies.
Phew! Way to hang in there for all these definitions!
If we missed a term that’s been making you scratch your head, ping Andrew on Twitter, and let him know! We’d love to translate more terms into plain english for you.
This post was originally published on July 13th, 2017. We updated the definitions, plus added some new terms, in January 2018.