Your mission as tech founder
This post is the first of a series about the evolution of tech founder from the early beginning, to becoming CTO and manager in a startup.
I’ll try to depict my learnings, but also things that other founders experienced in their journey. I’m looking for the stories of other founders so don’t hesitate to contact me!
In my different projects (MyK Applications, CovEvent, Seety), I always joined as technical co-founder. As an engineer and self-taught programmer, it’s logical that I was in charge of the technical part of the different projects as my cofounders were more business backgrounded.
As tech founder, it’s easy to understand your tasks as you’re, usually, the only one in charge of the technical aspects of the project at the beginning. First, your mission is to build the MVP to prove the need of your company’s solution. Then, you’ll develop the first product that’ll be sold to customers. Building those two isn’t the same at all, this article focuses on those differences and how to approach each of them.
Create an MVP: Prove the need of the market
First of all, creating an MVP (Minimum Viable Product) doesn’t always require code. Because your mission as tech co-founder is to be fast and lean, it’s sometimes interesting to discourage a coded MVP on “Day one”. There are numerous of no-code solutions that can help create an MVP to simply validate the need and the market without writing one line of code. Tech persons always want to code directly, but it’s usually a waste of time.
Tools like Zapier, Airtable, Google Sheets, etc., can be used to create an MVP without having to code. Use them extensively and if you’re missing blocks, use small scripts to connect them. They all have APIs.
The MVP doesn’t have to be perfect, in fact, if you’re proud of it, it’s too late, it’s not an MVP anymore. So don’t open your IDE directly, first, look at workarounds that’ll allow you to create something simple, to validate the need.
Fun fact: The first MVP of Dropbox was a video montage, nothing was developed!
When the MVP is released and you have some feedbacks/users, you can open your IDE and start developing something. In that case, you are working on the first version of the product.
First product: You’re building the basement of the product
As an engineer or tech person, when you join an entrepreneurial project, it’s natural to be in charge of the technical aspects. You have to build the first product that will be the basis of something bigger (if success is there), without building something too complicated that will take forever to build.
For me, the key responsibilities of the tech founder at the beginning is to understand that you’ve to build something quickly, that will meet the first customer’s requirements, but that can also be adapted for the future. You don’t want to rebuild everything as new features are asked, and you don’t want to develop all the future features in advance as you’ll waste a precious time at the beginning of the project.
The first decisions you make as Tech founder will be key for the development of the product and company. A bad tech choice at the beginning, will likely slow you down in the future as the company scales It can be related to the technical debt problem). But on the other hand, you cannot build the perfect foundations at the very beginning of the project, and it’s impossible to predict how the product will evolve.
Don’t forget: You are a cofounder
Never forget that you’re a founder of the company, even if you joined the team after they met. If you’re the first tech person in a tech company, you are a founder. You shape the product from its beginnings.
It can be tempting only to focus on product development but as a startup founder, you are in charge of a bit everything. You’ll likely have to do some marketing, sales, finances, etc. Your main focus is technology but you have to be ready to be involved in everything in the company.
The RACI matrix
While writing this blog-post, I discovered the RACI matrix, which is a really nice way to understand how you have to be involved in each task/topic of the company and be sure that everything is handled by someone.
Create a table with two dimensions: Each topic of the company (Sales, Product dev, Finance,…), and for the second dimension, each member of the team. Then, for each cell of the table, put R, A, C or I for the following:
- Responsible: Are in charge of executing for that topic. You need at least one R per topic/task.
- Accountable: Are accountable of the topic. You make sure that the R’s execute correctly.
- Consulted: Are consulted by A’s and R’s for guidance when executing tasks.
- Informed: Are informed of the result/progress.
This matrix helps to understand the implication of each founder for each aspect of the company. Normally, as the first founders in the company, you’ll be involved in everything. As the company evolves, this matrix will also evolve and each founder will be less involved (at least less responsible).
Here is an example of a RACI matrix for a startup of 3 founders.
Advices for tech founders
The right tech
Choose a technology that you understand, are comfortable with and that’s polyvalent. For example, I always used NodeJs as I know Javascript pretty well (At least, I hope), and the community is huge, so you’ll find a lot of packages/modules that can help you develop faster. Finding good Javascript developers is also not that complicated as Javascript is currently hype.
All those aspects also apply to Python or Ruby for example.
A good indicator is the StackOverflow Dev Survey. It shows the loved techs, but also the most used ones. If people use those technologies, it cannot be a bad idea to use the same, just be sure that the type of product is the same. For example, using C/C++ for a website is possible but less easy and common than Javascript. However, C/C++ is better for high-performance/embedded development.
Don’t over-engineer
As dev, we always want everything to be perfect, to be performant and clean. For the MVP, it’s not the case, build something easy and quick, it’ll not be used in the long term. The idea is just to have something working to be sure of the need of your product.
Even for the first versions of the product, you can be quick and dirty, it’s normal to have chunks of code that have to be rewritten in the future, just leave a note in the code. You’ll clean those when you’ll have more time/resources.
It’s also not important to have something that scales at the very beginning. For example, for Seety, our first backend was relying on a single 1.25€/month VPS (shared with other personal projects). It was not designed to handle huge peaks of traffic, but as we weren’t sure of the success of the app, we wanted to try before using a more expensive cloud offer. It was not scalable, not resilient, and the code wasn’t clean at all, but it proved the need of the market for our solution, without taking too long to be developed and costing too much.
The only aspect to keep in mind when working on the first versions of the product is that this will more likely be the basement of the product for a longer time. Be sure to be comfortable with the tech as you’ll not want to change your stack completely while managing multiple customer’s requirements and correcting issues and bugs from them. Try to choose a stack that’ll fit for the longer term.
This post is the first of a series about the journey from tech founder to CTO/Manager. Don’t hesitate to give feedback and follow me on Twitter to not miss the next posts!
