What The Non-Technical Entrepreneur Needs To Know About Tech

You’re a non-technical entrepreneur and you have a business-driven vision for your startup. As an entrepreneur, you don’t need to be a technical expert. However, you do need to know the basic concepts because many tech decisions are business decisions.

By the end of this crash course, you will have gained the necessary tools to have an educated standpoint when undergoing meetings or interviews with potential tech partners  -  whether that will be a CTO, a team of developers or a tech agency.

Below you’ll find the content in both video and written format. Feel free to choose the one you like best.

Picture this scenario: Your potential tech partner only talks in geek jargon and you understand at best 10% of what he says. You have two options:

Option A: As a non-technical entrepreneur, you admit that you don’t understand. This will put you in a weak and disadvantaged position and risks making you look unprofessional. An important thing to remember — tech stakeholders tend to see entrepreneurs with zero software knowledge as naive “muggles”.

Option B: You pretend to understand because you think they’re a genius and accept whatever they say because you don’t want to look stupid This risks you giving them full power and losing control. You have to remember that just because you can’t understand 90% of what they say does not make them a genius. You will probably be in the same position regardless of the tech partner if you don’t have the basic concepts.

Luckily there is an Option C — learn the basics so you’re able to:

• Follow a discussion with the tech stakeholders, and

• Make educated tech-related business decisions

If by the end of this crash course you still can’t understand 90% of what your potential tech partner is saying that’s probably more to do with their communication skills — not your knowledge base. So the minimum software concepts you need to master are:

• Mobile vs Web

• Frontend vs Backend

• Basic web concepts (HTTP, IP, URL & DNS)

• Database

• NoSQL

• Query

• Authorisation & Authentication

• API

Mobile Vs Web app

Let’s start by tackling some common misconceptions surrounding Mobile development & Web development. Unless you are creating a game or augmented reality app there is not a major difference between what is possible on a native mobile app and a web app. In the majority of cases, they do the same. The major difference is User Experience (UE).

I’m not talking about User Interface (UI) here. Thanks to responsive web design you can have a similar interface with both Web and Mobile apps. I’d say the main difference is the way you access it — A mobile app requires you to download it from the App Store (iOS) or Google Play store (Android) and there they are, on your phone just a tap away. Whereas a web app runs on your browser, for example, Google Chrome, Safari or Firefox. You will access the app through a URL.

Remember as a non-technical entrepreneur, deciding between web development and mobile development is not just a tech decision but also a critical business decision. In conclusion, we can use desktop and mobile apps to do pretty much the same thing, but you should pick one or the other for different business purposes.

Frontend vs Backend — an introduction.

Let’s take a minute to understand Frontend (FE) & Backend (BE). Think of these two as the body and the mind of an app where the frontend is the body and the backend is the mind. As we all know the body cannot live without the mind and vice-versa. This is also true for frontend and backend.

In your day to day, whatever app you are using all we see is the interface. Our experience as the user starts and ends there. But most probably you are on a device that is connected to the internet. The frontend is the code of the app running on your device, and it’s responsible for:

• Requesting information from servers

• Showing the information in a User Interface (UI)

• Getting User interactions

But this is only half of the story. There’s a whole universe underneath the surface — which we call the backend. The backend is all the code running on the servers. The backend is responsible for:

• Talking with other machines

• Storing data

• Serving data when requested

We usually refer to BE as The Cloud, this is nothing more than a huge group of web servers — and a web server is just a physical computer system that stores information and processes requests. This includes our code files (the app itself) and the databases we need to make that app work.

It’s really as simple as that!

Now we know what a server is and its basic functions let’s go back to get a deeper understanding of frontend and backend.

With such massive internet activity all over the globe, how can the frontend and backend communicate? How can servers handle so many requests and always manage to serve the right information to the right device? It’s all thanks to the following concept:

HTTP

HTTP is the foundation of the internet. A protocol, or set of rules, to determine how machines communicate. From a user point of view, HTTP created the hyperlink concept — which is how you are able to navigate the internet. Thank you, Tim Berners-Lee, for giving us HTTP — without him, you wouldn’t be reading this article right now

IP Address

The next key concept IP address.

Essentially the IP address is like a phone number used to call the server where the information you want to access is stored. Think of it this way, you want to access something in the cloud, let’s say an image:

• First, you’ve got to know which server its located in

• And then inside the server, it works like a folder system

• Then the server finds and serves the image back to you

This may look simple — but the only problem is that in this vast and immense cloud there are millions of servers connected to the internet and, unlike phone numbers, the IP addresses are nearly impossible to remember. For example, try to memorize:

Sure, you can probably memorize these… But now imagine all the servers you access per day, per week, per month. Would you like to try and memorize all of those numbers?

Me neither.

But thankfully someone created the next concepts we are going to cover — URL & DNS.

URL & DNS

The URL is like a readable address that matches to an IP. While DNS is a vital part of the internet infrastructure that makes this match.

The DNS services were invented by, Paul Mockapetris and Jon Postel. They are responsible to match IPs with URLs. A bit like a huge telephone directory that has all of the URLs in the world matching to the right IPs.

Database & Storage — Two Different Beasts

The Database is the know-it-all, the memory behind everything. Ther is another classic misconception around this topic — are databases and storage the same thing? The answer is: “They are not”.

Storage is where we keep things. Everything, in fact, from the code files (the app itself) to all kinds of assets like images, videos and, of course, databases. So whilst in the storage (or server) we store everything including databases, in the database itself, we only store organized data and information.

Think of a classic database as a group of connected spreadsheets, it is composed of a number of tables and they can all be connected. A classic relational data model looks a little bit like this:

In such a data model we represent the structure of each table and the relationships between them.

This may seem a little vague, so for the remainder of this article, we will use the LinkedIn app as a case study to give you a real-world example of how we can apply these concepts.

As you can imagine LinkedIn has a very complex data model, so let’s look at a simulation of 1% of the complexity to understand how it works.

Let’s start by looking at these two tables:

On these tables we have:

Members: This consists of all the relevant data regarding the members where we have per member the columns:

• Member ID (unique ID to identify the Member/user),

• Date Joined,

• First name,

• Last Name,

• Email address,

• and all the personal information specific to that user

Experience consists of all the member’s working experiences (job positions):

• Experience ID (to identify the job position),

• Member ID (to identify the member with this job position),

• Company Name and Logo,

• From Date (when the person started this job position),

• To Date (when the person ended this job position),

• All other data relevant to each job position…

Members and experiences are connected in the relation of one to many. This means that each member can have multiple work experiences. Now let’s take a look at the tables to understand the relation:

We can pick someone from the member side — for example, Karen — who has the Member ID “123”:

When we look up her Member ID in the Experience table we discover she worked at Facebook, then Google and finally My Startup Inc. We even see that she’s still working at My Startup Inc. because the table has a “From Date” but no “To Date” meaning that she started but didn’t end yet this job position.

Now let’s look at Member connections:

Member Connection consists of all the member’s inter-connections (as a user our Linkedin Connections): This is where all members’ relationships are stored:

• Connection ID (to identify the relationship),

• Member ID (to identify the inviting member),

• Invited Member ID (to identify the member being invited),

• Invitation Date (when the inviting member requested the connection),

• Acceptance Date (when the Invited Member accepted the connection invitation)

This relationship is many to many, meaning any member can have multiple connections and any connection can have more than one Member — so looking at the tables we see:

Karen, as the inviting member, identified in the first column as “Inviting Member ID”: 123 invited 3 people, identified in the “Invited Member ID”:

• John — ID 42

• Mary — ID 942

• Peter — ID 452

We can also see that John and Mary have accepted their invites while Peter is yet to accept his — as the cell for his ID’s “Acceptance Date” is blank. This means for Karen, Peter will show as not accepted whilst for Peter, Karen will show as a pending invitation.

NoSQL

The above terms all mean the same thing. NoSQL became extremely popular in the startup scene. Although it is referred to as non-relational doesn’t mean you cannot create relations.

A Relational DB has tables all connected together whereas a Non-Relational DB has a collection of Documents — also connected among each other.

There are many differences from a tech standpoint but what I want you, as a non-technical entrepreneur, to take away is this huge difference:

• Relational databases tend to be faster, in some cases, but are much more rigid structures. This means that whenever you want to change the structure you might break the data consistency.

• The non-relational, on the other hand, are a lot more flexible. You can change the relations every day and the structure will remain intact. 
  It is for this reason that they are widely adopted by early-stage startups because in an MVP (Minimum Viable Product) the database structure will potentially be changing every day.

So unless you are 100% sure about the Database structure from day one you should have a structure that allows you to iterate with ease.

The Query

Querying is the act of requesting data from a database. Think of it like this:

There are over 630 million users on LinkedIn — the database looks something like this:

But about a few million times bigger.

So if you want to find Waldo on LinkedIn you don’t want an endless list of over 630 million users one by one until you find him.

You just want to search and find him.

Note: looking at the entire DB user by user is also performing queries but “search” is by far the simplest way to explain database queries.

Search parameters are the query criteria for example:

• I log into my LinkedIn account

• I want to search for people in a certain location

• So I filter by location — I choose the UK & Switzerland

• This gives me 29 million results

So this is our User Experience (UE) to perform a very simple query — but what’s happening in the database?

Recap: I wanted to find users located in the UK and Switzerland and I want to see their:

• Profile Image

• Name

• Current Work

The process is as follows:

The query starts with selecting what we want to see

We’re saying “Hey database, give me the image, name and current job position” we still didn’t say from whom…

Then we select the table we want to query

In this case “members”

The next step is “where”. Where is the query criteria, in this case, we’re looking for:

• Location — UK or CH (Switzerland)

The final part of this very simple query is pagination. I don’t want to see all 29 million users in a single page — it would kill my browser! So we ask for 20 at a time.

“Offset” stands for “Page Number” in a UI analogy — so we are asking for 20 results per page.

Don’t get me wrong this is a very simplistic way to explain all of this, but just to illustrate, in the case of LinkedIn say you want to add a criterion — let’s say “First connection” this hypothetical query would look somewhat like this:

We would need to create an “inner join.” This is still relatively simple — just not as simple as our first example. Note: don’t waste time going deeper into queries for now.

Public & Private

This is an easy topic because the names are self-explanatory.

• “Public” is all of the public information or a public page that anyone has access to. In theory, you can access all of the public pages in the world.

• “Private” is a page that only logged users can access, and in some cases only certain logged users. This is done through Authentication & Authorisation.

Authentication & Authorisation

Authentication — “Authenticated users” are “logged users”, meaning that once you’re logged you are authenticated. As an authenticated user you have access to certain private sections of the app, but not necessarily all of the private sections.

That’s where Authorisation comes into play.

The system is always looking at the user activity and every time a user asks to: Access a page, Access Information, Perform an action. The system will check the protocols (access rules) and may, or may not, grant authorization to the user.

• Let’s go back to our case study, LinkedIn. Picture this scenario:

• I log in again and see that I have some unread messages,

• so I open the last message I received.

• This message has a specific URL,

• I copy the URL and share it with my colleague.

• When he tries to click that link he doesn’t have access — because despite the fact that LinkedIn recognizes him as an authenticated user it also realizes that he does not have the authorization to access my messages and the protocols have blocked the action.

Here is me in my messages on LinkedIn:

Here is my colleague on his account trying access the exact same URL:

This is the difference between Authorisation and Authentication, in a nutshell.

API

Do you remember the distinction between Frontend and Backend that we covered earlier in the article? On one side there is the backend and the other side the frontend. Well, an API is the interface through which the backend exposes its data to the exterior, almost like a gateway.

The API handles:

• Authentication

• Authorization

• Queries

But the most beautiful think about the API? A common language — meaning that whatever the language in the frontend and the backend they speak a common language through the API. This is why APIs are very important because it lets you expose your backend to any frontend, as well as to other backends.

Let’s set a scenario to understand this common language:

There is one app called My App. My App has a frontend in Angular9 and a backend in .Net.

In the analogy we’ll use:

• The FE speaks Mandarin (standing for Angular9)

• The BE speaks Hindi (standing for Java)

• The question is how will they communicate?

• The answer is they’ll use English (the common language they share through the API).

The greatest outcome as a founder is with an API or microservices architecture we’ll be free to have separate parts of our app in different languages (the best for each case) and they can all communicate: In terms of our case study, LinkedIn has only one backend however they have multiple frontends in different languages:

• A Web App

• An iOS app

• An Android App

Thanks to API all three frontends can communicate through the common tongue to the backend.

Wrapping Up:

If you’ve stuck with me this far you can now make informed business decisions on some of the tech requirements for your startup, including whether you need a mobile or web app, because have the foundation knowledge on both the hardware and software side of technology — from Frontend vs Backend to Databases & APIs.

Now you have the power to have those geek conversations with potential tech partners and understand more than 10% of what they say.

RED FLAG!! > If you still can’t understand him after this Crash Course, the problem is on him, not on you, this means he doesn’t know how to adapt his communication to different stakeholders if this is a problem now it will always be a problem, every time bigger.

Just remember — if you are talking to a potential tech partner this is a very key business decision. Here’s a guide I wrote about this topic, a step by step guide to picking the right tech partner, either CTO, dev agency or team of developers.

As a non-technical entrepreneur, you may feel tempted to let go of control as your tech partner will, and should, know more about tech than you — but some tech decisions are intrinsically linked to the success or failure of your startup because they are business decisions.

Many successful startups started with a non-technical entrepreneur, my own included 7 ventures ago — the fundamental tech knowledge we’ve covered will put you ahead of the curve and now you too will be able to communicate strategy in your tech partners language.

Daniel De Castro Ruivo,
Co-Founder at Altar.io

This post was originally 

published

at by Daniel de Castro Ruivo, Founder at Altar.io.