In order to find a tech-driven startup, one doesn’t necessarily have to be an expert in all things tech. However, if you are a non-technical founder, it is absolutely important to know the basic concepts because many tech decisions are business decisions.
But first, let us examine the three most common scenarios a non-technical founder is likely to find themselves in.
Scenario A: As a non-technical founder, you outright admit that you don’t understand the first thing about tech. This could put you in a weak and disadvantaged position and risk making you look unprofessional.
Scenario B: You pretend to understand because you think your developer is a genius and accept whatever they say because you don’t want to look…well, stupid. This risks you giving them full power and losing control.
Scenario C: You decide to learn the basics so that you are able to a) follow a discussion with the tech stakeholders, and b) make educated tech-related business decisions.
Out of the three scenarios above, Scenario C is the most desirable. Scenarios A and B may work under certain circumstances, but they can also spectacularly backfire and lead to expensive rebuilding, which is something a young startup could really do without.
Let us now move on to a few basic concepts which you need to be aware of, in order to at least commence a discussion with a technical stakeholder.
Native App vs Web App
Web Apps have evolved so much in recent times that sometimes, it can be hard to choose between web apps and native apps. In reality, there is very little difference between the two unless you are building something resource intensive such as a game or a VR app. The differences will largely become apparent only when it comes to the User Experience (UX).
Note: Do not confuse User Interface (UI) with UX. UI refers to the look and feel i.e. the outward design of an app, while UX focuses on gaining a deep understanding of users, what they need, what they value, their abilities, and also their limitations. It also takes into account the business goals and objectives of the group managing the project. UX best practices promote improving the quality of the user’s interaction with and perceptions of your product and any other related services.
A native mobile app will have to be downloaded via a platform such as the App Store (iOS) or Google Play (Android) and is generally built to take full advantage of all capabilities on the end user’s device. A web app, in contrast, is essentially a mini-version of a website itself.
As a non-technical entrepreneur, keep in mind that deciding between web development and mobile development is not just a tech decision but also a critical business decision. While it is possible to use native mobile apps and web apps to accomplish the same thing, your choice needs to take into account the current functionality of your app, the feature roadmap, and the user’s needs. You can learn more about choosing the right tech stack for your app here.
Frontend vs Backend
Perhaps the most frequently used words in a developer’s vocabulary, the frontend refers to the code of the app running on your device, and it is responsible for:
- Requesting information from servers
- Showing the information in a User Interface (UI)
- Obtaining user interactions
But this is only half of the story. There’s a whole universe underneath the surface — which is what we are referring to when we say ‘the backend’. The backend consists of all the code running on the servers. The backend is responsible for:
- Talking with other computers
- Storing data
- Serving data when requested
The backend of an app communicates with the gazillion other devices connected to the internet through elements such as HTTP (which is a protocol, or set of rules, which determine how computers communicate), IP addresses (which is like a phone number used to identify a server where information is stored), URLs (web addresses such as google.com), and DNS (a service which matches IP addresses with URLs).
Database and Storage
Though these terms are often used interchangeably, they are in fact, two completely different objects.
The database is the know-it-all, the memory behind everything. It holds data in some predefined format. Storage, on the other hand, is a place used to store a variety of data that may not even be related to each other (think code, images, videos, etc.)
A good way to understand a database is to think of it 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 like this:
NoSQL
NoSQL is a type of non-relational database that became popular with startups due to its high scalability. Though it is referred to as a non-relational database, that doesn’t mean that NoSQL is incapable of creating relationships between different data.
If you are building an app that handles information you will be dealing with databases a lot. But here’s what you need to remember:
- 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.
- Non-relational databases, 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.
Unless you are 100% sure about the Database structure from day one you should have a structure that allows you to iterate with ease.
APIs
Recall the distinctions we made between the front end and the back end much earlier in the article. Now, how do you get these two sections to talk to each other? That’s where an API comes in.
An API is a common language that allows the backend and the frontend to communicate with each other, thus opening up the opportunity for you to connect your app to a vast variety of third-party services.
An API or microservice-based architecture, should you use it, will allow you to build different parts of your app in different languages, thus giving you the freedom to choose the best tools for each individual module. For instance, consider how LinkedIn is built. LinkedIn may have only one backend but several frontends such as a web app, an iOS app, and an Android app. All these individual modules can easily communicate with the backend with the use of a common API.
That largely covers the basics of what you need to know about tech as a non-technical founder, and we hope this information helps you make informed business decisions that can be critical for the growth of your business. By now, you should also be able to understand your technical stakeholders better.
If you can’t, the problem may very well lie with your technical partner(s) and could mean that they don’t know how to adapt their communication to suit their audience. In that case, you would probably be better off looking for a different technical partner to avoid running into bigger, much costlier problems down the line.