In this article I will share the story of how I became CTO of a software as a service (SaaS) company. It all started about 3 years ago when I was going to hackathons for fun.
At the end of the article you can find some tips and advice I would give to aspiring entrepreneurs as well as some reading recommendations.
It was – and still – is a wild ride!
Although I have a good knowledge of entrepreneurship, don't just take my advice at face value. Learn from books, from other entrepreneurs, and from your environment in order to triangulate how best to act in a given situation.
My First Hackathon – Which I Lost
It might sound off, but I had no interest whatsoever in entrepreneurship or business 3 years ago. I was more of a researcher in spirit than an entrepreneur.
From studying memory at the molecular level, to helping schizophrenic patients learn better, or predicting consciousness recovery in patients with traumatic brain injuries, my mind was deeply focused on the frontiers of science.
However, I had a deep passion for programming and for finding ways of building tools that didn't exist before.
Like the time I built a brain computer interface that was compatible with a Transcranial Direct Current Stimulation electroencephalographic headset (that is, it stimulates the brain by giving shocks and lets you control a kind of ping pong game). I just love to build stuff.
So three years ago, my brother wanted to find a new job as a software developer. We figured out that we could attend hackathons to help him get noticed by recruiters.
It was my first hackathon so I was pretty excited to spend two days building something. Our team was composed of myself, my brother, his friend, and one more member (who didn't do a lot, but was still there).
It was two days of heavy coding, and at the end we came up with a pretty cool algorithm to pattern match people with jobs given some characteristics.
On top of that, I met nice people that, like me, love to build stuff. We ended up among the finalists and came in fourth during the final presentation.
What I learned From My First Hackathon
It was a bit of a bummer not to win, but I realized something important then: except for the participants, no one really cared what I coded during these two days.
It was mostly the presentation of what we wanted to build that mattered. We should have spent a bit more time making a very compelling PowerPoint instead of focusing on the development of an algorithm!
It was a fun learning experience, but my brother didn't get a job out of it – so we were back at square 1.
My Second Hackathon – in Which We Won a Special Prize
I was ready to take a small break from hackathons for a while. However, my brother decided to sign us up anyway. So his friend and I to go to another hackathon right after the first one. I would have refused as I had other stuff to do, but he had already paid the sign up fees.
This hackathon was a bit bigger than the previous one and there were still a bunch of recruiters there. We figure that this could be our second shot at getting him a job.
The theme of this hackathon was open data and environment. So we were in a good position to make something cool with my background in machine learning.
Knowing that the presentation was everything, we decided to be a bit more strategic with this hackathon. We combed all the different prizes we could win and selected the one with seemingly the least competition. The project would deal with the prediction of combined sewage overflow.
We then split up our team of four (another friend of my brother's joined in) so that half of us were working on the coding and the other half on the presentation.
The name of our team was “Égout Quebec” which translates to Sewage Quebec (branding wasn’t our strength). Here is the excerpt from our competition log on DevPost in French:
ÉGOUT QUEBEC permet de prédire le débordement des égouts et d’en avertir les amateurs d’activités aquatiques. Ainsi les personnes désirant aller faire des activités aquatiques pourrons éviter les zones polluées par les déversements d’eau usée. De plus, des conseils seront dispensés aux gens des différents quartier, de façon à réduire les risques de débordement.
ÉGOUT QUEBEC utilise une technologie basée sur une intelligence artificielle. Celle-ci peut déterminer lorsque les égouts déborderont. Ses analyses et calculs sont basés sur des données disponibles sur le site de donnée Québec. Finalement, les différentes villes auront avantage à utiliser ÉGOUT QUEBEC.
Grâce aux prédictions et aux analyses de la plateforme, il sera possible de concentrer les ressources de la ville aux endroits les plus problématique.
All this basically translates to “we found a way to solve the problem using a random forest + a bunch of data”.
We actually ended up winning a $1000 prize, which was huge at that time! We even got a nice glass trophy in the shape of a water droplet. It was less challenging than the previous hackathon because we had a better plan for what we needed to do.
What I learned From My Second Hackathon
This hackathon made me realize that presentation was indeed important. But I also discovered that focusing on problems that people don't find interesting is a good way of increasing your chance of coming out on top!
Winning felt good and I was ready to take my share of the $1000 prize and call it a day...
My Third (and Last) Hackathon – Which We Kinda Lost Again
However, the $1000 prize came with an automatic fast-track to the semi-final of yet another hackathon! This one had higher stakes with a $25,000 prize.
We met up at a coffee shop to figure out if we wanted to split up the money or to use it in order to take our project to the next level.
After looking at the other participants' projects and the rules of the competition, we decided that we actually had a good shot to at least get to the finals. This would unlock some more funding which we could use at will and would give us a nice trip in the summer to a lake in Ontario.
This hackathon wasn't like the others in the sense that it ran for the whole year. It was more of a take-home hackathon, which was great for me since I didn't have to do that insane two-day time crunch routine over a weekend.
We changed our name to EGC Labs and managed to get a website together to advertise our sewer overflow prediction solution (which was working surprisingly well). We then went to the semi-finals competition in Ontario, and to our amazement we moved on to the final!
This was great! We had a very good shot at winning more than a small stipend, and maybe starting a business out of this thing. To help us bootstrap ourselves, Aquahacking generously gave us $2000 and École de technologie supérieure (ÉTS) gave us $1000 for travel expanses.
However, we still didn't have any customers for our solution, which was a bit problematic.
We tried to contact a bunch of cities in Quebec in order to see if they would be interested in our sewage overflow application. We had some pretty advanced discussions with a few cities, however their process was so slow that we got very near to the finals without any concrete validation.
The final was a 5 minute presentation in front of a big audience with some investors present.
Things got a bit more tricky when we got closer and closer to the presentation date. The rest of my team started to become less and less responsive. I ended up not being able to reach my brother's friend who had joined at the HackQC competition.
This quickly followed by my brother losing all interest in the competition and focusing on other stuff. We were left with myself and my brother's other friend (Félix) who joined in the very beginning.
He was also starting to slip out of the picture because nothing seemed to be moving forward, as I was the only one left coding. I wasn't very interested in that project either, however one thing I hate is half-backed projects (even more when they are public).
I felt that it would have been a waste to stop so close to a conclusion. So I took it upon myself to jump start the project by coding the app's user interface, getting some branding going, and creating our business cards for the event.
As things started to pick up Félix started to become more and more involved (which was a blessing because he was the one pitching!).
We were still finalizing the PowerPoint the night before the presentation in the hotel room. After all this hard work we had something pretty solid (by my standards at the time, anyway). We've ended up winning fourth place in the competition:
We went from a team of 4 to 2 people and were able to get that far. However, it was exhausting since I had to do so many different things that were not in my core zone of competency.
What I learned From My Last Hackathon
I learned two very important lessons during that adventure:
- Having motivated teammates is the most important asset in any endeavor. If we had everyone pulling their weight we would have had more chance to win!
- For a startup, having clients is the ultimate measure of success. We did everything right, except making sure that we had paying customers. In the end this is what kept us at 4th place.
We won a big $0 in that part of the competition, and once again I thought that was it. I had coded some cool Flask applications, went to the final of a big hackathon, and learned some valuable lessons. Until I realized...
How I Learned About Entrepreneurship at An Incubator
Being part of the finalists of Aquahacking automatically gets you a spot in one of the provincial incubators for startups, which happened to be Centech for us in Québec.
I didn't really know what an incubator was (except in a biological sense), so I wasn't particularly excited. We had to make a pitch for our "startup" to the incubator panels even though we had a reserved spot. I let Félix do it without me, as I had other stuff to focus on.
At first I didn't go too often to the entrepreneurial classes and I was starting to think that this whole hackathon-thing was becoming a huge time-sink. However, I stuck to it because Félix was very motivated by the whole experience.
So I decided to give it a serious shot. I started attending the entrepreneurial classes (which were amazing), I did the homework, and I tried really hard to make our sewage company work.
Frankly speaking, it was amazing. It was genuinely fun to try and make something novel. And being mentored by people that had built incredible products that helped millions of people was incredible.
The class that I was in was also very motivating, as we had people from all backgrounds and oddly enough most of them were graduate students, like I was!
I really got the bug for entrepreneurship. It was like doing research, except I could directly see the results of my experiments in a matter of days. It was like combining the pleasure of discovery I had while doing an experiment with the freedom of programming for a side project.
However, after reading the books and learning the material, I realized that we'd done everything upside-down for our budding startup. We had built the technology before even validating that there was a sustainable business out of it (silly us!).
We were ready for our very first pivot, which in entrepreneurial jargon means tweaking your business in a significant way in order to not crash and burn.
How We Made Our First Pivot After Learning that Our Startup Idea Was Doomed
Our combined sewage overflow predictor was working great. However, no one was willing to spend money on it.
We were targeting cities in order for them to be able to proactively do something about the overflow of raw sewage into their rivers (which, by the way, is a worse and more frequent problem than you think). But these cities had such a long cycle to sell to that we would never be able to grow this business.
One thing that we realized during this project was that the majority of the data that was available for the competitions were in a very bad shape. It took us many hours of cleaning and we had to develop some very custom toolsets in order to make the cleaning efficient.
We had also talked to a few of the judges at Aquahacking and what they were most interested in was the portion of our business that related to data cleaning.
So that was it! We would become a data cleaning company. For about three weeks we were frenetically searching for customers, making plans on how to make this type of business work, and coding outlier detection algorithms.
However, after meeting with our mentors at Centech, we realized that what we were building was a service company. Almost no data is similar, especially when it comes from different sources.
The amount of domain expertise we would have to gain in order to be efficient in one industry would not necessarily transfer easily to another industry. There was a lot of manual work involved in this and all our ideas for making it more automated were failing.
Now, there is nothing wrong with making a service company. It's a great type of company if you are very interested in your industry. But we did some amount of introspection and we realized that we weren't really passionate about data cleaning.
We were passionate about automating work and improving efficiency through technology. Building a data cleaning company where most of the work would be manual and not very efficient wasn't very exciting for us.
We were ready to make our second pivot, which would be our largest so far.
How We Made Our Second Pivot
During the Centech program we had met two other entrepreneurs that had a problem that was complementary to ours. They had a lot of validation from potential clients whose problem could be solved by technology. However, they didn't have the technical skills to make the technology required to power their business.
I had helped them out a couple of times in order to get them started with building their web application since I'd already done something similar for EGC Labs.
Helping out other entrepreneurs without expecting something in return is very common in this type of environment. The more I helped them, the more we realized that we could get way more done if we were a team of 4 instead of two teams of 2.
We went for lunch to discuss what a potential "merger" of our two ideas would look like. After discussing for a week, we decided to ditch the EGC Labs project completely, as it had the smallest chance of success. Instead we would join forces with their idea, which was called GRAD4.
That was the second pivot for Félix and me. It meant completely dropping a project that was leading nowhere and joining another one that we were much more excited about.
During the next weeks, we were absolutely crushing it. We did everything right. We officially incorporated our company. We made a few plans as to what the actual application would need in terms of functionality so it would deliver value to our potential customers. However, we didn't wait for me to complete it to start selling it!
The other two co-founders were already on the road talking to people who'd showed interested. They were gathering checks for a 1 year subscription to our platform, which didn't exist yet. The $500 yearly subscription would start when we launched the product and we were very upfront that we were in the process of building it.
Getting people interested in your project is one thing, but getting paying customers before building a SaaS app is the holy grail of business validation. By doing so we were able to get about 15 checks that would help finance the development of the product.
We also won a $1500 elevator pitch competition around the same time because Félix was very focused on practicing his pitch.
All of these small wins compounded during the program and we ended winning a $15,000 prize at the end of the incubator called the Unicorn prize.
This was great, but more importantly we secured a spot in the next stage of the incubator which was the Propulsion program. This would secure us an office and some additional perks that would help our company succeed.
What I Learned From My First Startup Incubator
During that part of our young company's adventure I learned a few important lessons:
- Clinging onto an idea because it was yours even though all analysis tells you it's a bad one is usually a bad idea.
- A larger founding team is more productive than a smaller one. It also allows for cheaper labor as no one is getting paid at the start.
- Asking customers to pay for an in-progress idea is not as difficult as you may think. If the pain is big enough for the customers, they are usually very supportive of having someone fix that mess. Even if the probability of success is low.
- The technology part of the business is not that important.
We Have Money, Now What?
We now had gathered a fair amount of money and we had multiple options in front of us:
- Either we keep the money and pay ourselves.
- We keep the money and don't use it in case we fail to make the app and we need to reimburse people.
- We use the money to hire people to speed up the development.
The first idea was wasteful, and it would decrease the probability that our company would succeed. The second option would just let our funds sit idle. So we decided to go for the third option.
How We Scaled Our Startup Past the Founding Team
During that summer of 2019, we made our first two official hires to help me with the development of the platform. They were software engineering interns from the ÉTS (École de Technologie Supérieure). One intern would be focused on the backend side while the other would be focused on the frontend side.
Our product was a simple CRUD application that would allow buyers who needed metal parts manufactured and suppliers of metal parts to find each other.
It was basically a sort of marketplace where buyers would create what is called a request for quote and the suppliers would create a quote to say how much they could build the part for. Pretty simple!
The technology we choose to use was the following:
- Django + Django REST API for the backend.
- React + Redux for the frontend.
- Bootstrap for the styling.
- Heroku to host both applications.
- GitHub for remote source control.
Choosing the technology was up to me as the CTO, and I honestly decided to go with what I thought would be better in the long run. I was already familiar with Flask, however I knew a bit of Django too. Seeing that a lot of the functionalities I needed were already pre-built into apps made me lean toward it.
I chose React on the frontend side because I had played around with it 6 months prior and found that it was such an easier way to build applications than the traditional way I was used to.
However, in retrospect I think I would have greatly simplified the stack. I would have only used Flask for the following reasons:
- I was more familiar with Flask than with Django.
- We didn't need to have a separate frontend, as the application we needed to build was very simple. Simple templates would have been enough for a first proof of concept.
However, we went with this tech and we learned a great deal in the process.
What I Learned During My First Months as CTO
One lesson I learned from this first foray into making an application customers would actually use is that overthinking scalability is oftentimes useless.
Working with what you are already comfortable with and delivering something as soon as possible is much more useful as you learn more rapidly. This is actually what is most important in a startup.
The more learning you can do (about the business, what customers want, how to talk to them) the more probable it is that the next thing you try will work.
After a few iterations, we were finally ready to launch our closed beta with the customers that had already paid for our service.
How We Did Our First Product Launch (Closed Beta)
We were able to make the first version of the application at the end of the summer of 2019 and launched it for our users (1 month later than we promised). It wasn't pretty and it was barely working.
We had to babysit our users throughout the whole process and the buyer section of the application wasn't usable. We had to do the work manually for all our buyers while the suppliers were able to create quotes.
What was great, though, was that we continued to be able to get checks from people who were interested which helped fuel development. We made a few mistakes on the hiring side, though. We hired a friend of one of the founders who, although experienced, was a jerk to the other more junior developers.
This was the first firing I had to do, and I'm glad I did it. Creating an enjoyable work environment is much more important than technical prowess, because at the end no one wants to work in a bad environment for long.
Having people stick around for the long run in a startup environment is crucial for the company's success. I believe it is one of the reasons our startup is still alive.
As development was chugging along we realized that we had to structure the company a bit more than what we were doing. Thanks to being next to so many startups and successful companies at Centech, we could learn from each other.
During that year, we focused on getting financing going (this is a super important part of business and should be prioritized). We also focused on getting some sort of marketing going, making actual designs that made sense instead of winging it, and making sure our team was staffed by full-time people instead of only interns.
We also moved from the basement of Centech to an office space with windows on the second floor which was actually pretty nice! We maxed out the capacity pretty quickly, though, and the founders had to start working in the dining area of the building so that the employees had more room.
What I Learned From My First Launch
I learned a great many lessons after our first launch:
Don't do an official launch. It's useless. We put so much pressure upon ourselves to impress the paying customer with a pompous launch, and we were afraid that they would be mad at us if we didn't deliver.
The truth is they didn't really care. When we sent an apology email saying that we had to delay the launch no one complained. I'm pretty sure they were actually amazed that we were able to get something up and running so quickly.
Even if you have paying customers for your SaaS application, prioritize doing manual work over building an application. In retrospect, I would have made a simple form where the buyer could upload a Zip file containing the request for a quote which would be sent to the founders' email address.
We would then send out this request manually to the manufacturers we knew would be interested in this type of work. That would have delivered value way faster to our users and released the pressure on development.
It would also have validated a lot of hypothesis we had that would have accelerated the development work.
Stay focused on very few things and make sure that this focus is explicitly written down somewhere. At some point I was building a blockchain-powered smart request for quote because it was hyped up by one of the co-founders who knew someone working with blockchain technology. That was a solid waste of time and I'm glad I killed that project soon after.
We were starting to pick up steam and we finally had something that we could show the world. It still wasn't pretty, however customers saw the value in what we were building and we knew better what was creating value and what was not.
We were ready to open our beta to increase the amount of users in our application!
How We Opened Up Our Product to More Users
After tweaking the platform using feedback from our early users, we now had a better understanding of what exactly we needed to build. We were now ready to increase the amount of people using our platform and start to increase the output of the sales (which the founders did).
This put more pressure on our application and we started to experience downtime. We knew that we had to improve the way we were building this product if we wanted to scale to more users.
We asked an experienced software architect, now part of the team full time (thanks Karim!), to help us out. This really gave us a solid direction to follow. Here is what we changed:
- We moved to AWS to have more control over the cloud environment.
- We moved to Gitlab to have an easier-to-use CI/CD environment.
- We added automated testing to our application.
- We started to migrate toward Material-UI instead of Bootstrap.
After improving the way we worked, we now had a fully working CI/CD setup and a more robust application that was rigorously tested. The amount of downtime we experienced was drastically reduced and developers were more confident about the changes they were making. It was a more enjoyable development experience, too.
What I Learned From My First Open Beta
During that period, I learned that the minimal viable product (MVP) phase of the product is necessary. But when transitioning out of it you shouldn't hesitate to ask for expert help.
We now had sales giving us more clients (which were still a bit difficult to get, but coming along at a constant pace) and the application provided more value than before.
We were ready to ask for our first real investment!
How We Got Our First Real Investment
We applied for a funding from Front Row Ventures which is a venture capital fund entirely managed by students and which only invests in student-led startups across Canada.
We met with the people from Front Row, and explained what we were doing and where we were going with all of this.
We ended up having to do a 25 minute pitch in front of a full panel of students who were asking solid questions about the business and the technology.
This was great because we knew that if we got the funding we would not only have the cash, but also new connections that could be there to answer questions and make strategic introductions for us.
What I Learned From Getting Our First Funding
This was another important lesson I learned during that time: when choosing a funding partner, it's not only about the funding. It's also about how much help they can provide.
Front Row ended up opening many more doors for us and ensured that their investment had all the possible tools to succeed.
What Our Day to Day Routine Looked Like
Everything was going pretty well for us on the business side. However, the pace we were following was a bit worrisome. We were an archetypal startup where employees would come at the office from 9 to 5 and where the founders worked 80 hours a week.
Meeting on the weekends at the office to plan stuff out and clear up more tasks was routine.
I wasn't too happy with this because this type of work isn't sustainable in the long run – and I started to see signs of burn out in the others. We also weren't very structured, the documentation was poor, and we had almost no processes clearly mapped.
It was at that time that I started to read more about how to structure a company properly in order to maximize our chances of success (see readings at the end).
Then, out of nowhere, we started to hear about the possibility of a pandemic hitting our Canadian shores...
How We Reorganized When COVID-19 Hit
Some employees were very afraid of the virus and of getting sick. There were no cases in Canada yet, but some of the employees had family abroad in areas more advanced in the pandemic's course.
We started to think about what we could do and we realized that we didn't absolutely need to have people come in the office to do their work. All of the work could be done remotely just fine – it was just the culture that we'd set up that required people to show up from 9 to 5 every day of the week.
This type of schedule was directly taken from what we were all familiar with, but we realized that we didn't have to do like all the other companies we'd worked for.
We decided that we would allow everyone that wasn't comfortable going into the office to stay home. I personally decided to not show up to the office and most of our employees followed suit.
This was great because we soon realized that a lot of the shortcomings of our company's structure were hidden by the fact that all employees were available in the office every day. Everyone was always trying to setup a Zoom meeting at random hours or calling at any time of the day to ask for operational tasks status.
We also realized that people had a hard time finding where all the information was, and many different people asked the same thing many times.
I decided to read a bit more about how to structure remote work efficiently so we read the remote playbook from Gitlab and implemented some changes:
- We removed the silos between the different teams by making all communication public and via written messages.
- We organized the documentation so that people would put their files in a shared drive instead of sending them on the instant messaging app.
- We instated a Kanban methodology for all departments, not just the people working on the technology since tasks weren't properly tracked.
- We reduced synchronous meetings by only scheduling those that were necessary and by having the results of the meetings communicated in one form or another.
This helped a lot! However, it took time before it really took hold. People were still having private messaging discussions when everyone could benefit from what was said. Synchronous meetings were still the default for a lot of people to share information.
But it got better. By putting a lot of effort into making remote-work work, we were drastically improving our company's productivity to a level way above that pre-pandemic.
In a sense it was helpful that we were forced to experience remote work (as we were in full lockdown for a while) because it gave us the necessary buy-in from people that were skeptical that this was possible.
There was no other choice but to go all-in to remote work, otherwise the company would've just ground to a halt. We had employees to pay, so waiting the pandemic out wasn't an option.
In the business sense, we were very fortunate as our platform was useful for the manufacturing industry which couldn't do business in person anymore.
Some startups that we knew of weren't so lucky and their whole business was now impossible to operate within a very short time frame. Most of them had to close shop or do some radical pivot.
What I Learned From Pivoting to a Remote Company Structure
The first few months of the pandemic taught me some very important lessons:
Starting a startup is very, very, very risky. If you had started a ridesharing startup in 2019 and things were going fantastic for you, you would still have had to stop that business once the pandemic hit in 2020.
No matter how prepared you are, there are always risks and unforeseen events happening on a daily basis.
Working on the company is more valuable than working for the company as a founder. What I mean by that is spending time structuring the company and making adjustments to how people work in order to increase productivity is invaluable.
You can't expect employees to do that on top of doing their regular work. It's up to the founders to set up a structure that make sense and to always be improving it.
Remote work will improve your team's productivity compared to in person work (when possible) only if you take the time to make it work. Trying to reproduce an in-office way of working remotely will lead to an obvious decrease in productivity. Drastic changes needs to be made in order for this type of work to be useful and it requires a leap of faith.
We were still growing during that time as we were hiring more people to sustain our rapid pace. We also made a major pivot in how we were generating revenue by ditching our subscription-based model to a transaction fee model. This allowed our sales team to rapidly increase the amount of companies we enrolled in our application.
Our first version of the application started to show signs of not being optimally adapted given all the new information we'd collected from our customers. So we were working on revamping it with an improved design and user experience with a dedicated UI/UX team.
The Improved Version of the Application
We launched the revamped version of our app (this time without a hard deadline) and the reception was great. This is when I started to feel like we actually launched a real product and not a MVP to validate a need.
The sales of our product increased dramatically as the user interface was great and the experience made sense to prospective users. We went on to do some more major refactoring and clearing up technical debt.
We knew that the added load on our platform meant that we needed to have something cleaner to work with. This was important as technical debt will always creep up and you can't just always build features.
We were slowly emerging from the bootstrapping phase of the company to more serious territory and it felt great. We made some more hires in the customer care and the marketing side. We improved month after month how the company operated.
Around that time, we decided to implement two systems that would improve our productivity:
Objective and Key Result system: This really switched our whole mindset from working long hours to working on objective attainment. By having concrete goals that would improve how the company was doing, it allowed everyone to focus on what really mattered.
It also allowed us to stop tracking when people were working or when they were taking vacations. As long as the objectives were worked on, it didn't really matter what the employees' workflows were (as long as they were not overworking).
EOS System from Traction: This system was a very good foundational system to ensure that everyone stayed aligned. It really improved how our meetings were structured and laid the foundations for the vision of the company.
I used to scoff at the thought of having a vision or core values. But after reading the book and implementing it, I cannot understand how we got as far as we got without one.
This aligned everyone to a level that we didn't think possible and allowed us founders to make better decisions for the company.
It now felt that we were really running at a solid pace. Every month we had major improvements or good news in the company. The whole startup thing felt easier and was more enjoyable.
What I Learned From My Second Product Launch
I learned another good set of lessons during the time of the launch:
Your job as a founder is to "elevate and delegate". At a certain point, if you are still working on the minutiae of the work you are wasting resources.
It is usually way more cost effective to hire someone else that is more competent than you to do the operational work and to move on to another position that doesn't have staffing.
By de-risking and laying the groundwork for a section of the company that is weak you are ensuring that it's worthwhile to hire someone and that this person has something to start with. This is priceless.
No one can work 80 hours a week on different job types effectively. We realized this when we were looking at what the weakest points of the company were. It was always the spot where someone that had 3 different hats was working because there wasn't enough time to do quality work.
If you are working on 3 different positions as a founder and you work 80 hours per week, it is the equivalent of working as a tired part time worker. The documentation will be poor, the process will be non-existent, and mistakes will start to show up.
As soon as we saw someone work more than 40h a week it was a big red flag that we needed to distribute the load onto someone else.
Part-time and volunteer workers are usually a waste of time. Once we were picking up more speed, we found ourselves constantly waiting for the part-time worker or the volunteer to finish their part of the work. This was holding us back so we made it a policy to not hire part time workers again.
It's different for interns though, as they have a well contained work arrangement. For instance, we currently have 3 interns working on various machine learning projects as part of their PhD. This is perfect because the work that is given to them is well balanced and we know what to expect.
Around the time of the new platform release, we started our first accelerator programs.
The NEXT AI and EcoFuel Accelerators
I didn't really know what an accelerator was at that time. However by being in two I quickly understood the difference between an accelerator and an incubator.
An accelerator's job is to give tools to an already up and running startup to accelerate their growth. On the other hand, an incubator is where startups usually begin.
One thing that is very useful in accelerators is that they provide startups they select with funding. By doing the NEXTAI and EcoFuel accelerators we were able to get $100,000 in total funding!
It was way more fast-paced than the incubator we'd been in. We had virtual classes with incredible entrepreneurs and got technical classes with researchers in machine learning such as Yoshua Bengio.
We also got to meet other amazing tech entrepreneurs living similar challenges in trying to get a startup to scale during a pandemic.
It's at that time that we officially founded the more "research-y" side of the company that dealt with making AI models and working on the data we collected. We staffed that section of the company with PhD students and graduate master's students (and me!).
It's also at that time that we decided to raise our seed round of venture capital (VC) funding. We made this decision because we knew that we had something great, however we were in the type of business where we needed to scale fast to deliver the most value to our customers.
The more people use the platform, the more valuable it is for the people using it. Therefore, getting funding to crank up the sales and marketing is a must. We put our CEO on that full time as it is indeed a full-time job.
Around the time when NEXT AI was ending, we had one of our first major financial drawbacks that would forever change the way we saw failure in our company.
We thought that, just like at Centech, we were in a very good position to get the financing that comes at the very end of the program. However, we were in the finalists but not in the top 3 winner startup.
This was a major blow as we thought we were very solid during the whole program.
After gathering more information about why we weren't shortlisted, we realized that there was a major communication gap between what the organizers of the program thought we were doing and what we were doing.
They didn't realize how advanced our product was and were not aware of all the cool AI modules we were building to complement our offering.
What I Learned From Our First Startup Accelerator
This is where we realized a very, very important lesson:
Other people's perception of your startup is as (if not more) important than what you are actually doing. We couldn't blame the program organizer for having the wrong perception about our company when they weren't even aware of most of what was happening with our company in the first place.
There was so much cool stuff happening everyday, but the number of things we publicly showed was thin in comparison.
This was problematic and could seriously handicap ourselves in the future. This is when I made the decision to celebrate the wins of the company publicly.
Every release of the product, I would publicly acknowledge my team's work on our social media. If we were passing major sales milestones, I would make a statement out of that. A major advance in the AI research of the company would be public within the week that it happened.
I used to hate posting on social media as it felt like I was bragging, but it was one of the most important change we've made so far. By celebrating our wins publicly, we've increased by a lot the likelihood of good opportunities coming our way. This is now a vital part of the company that we leverage every day.
With our new understanding of how to best promote the company and improve our probability of success, we applied to two other bigger accelerators (Creative Destruction Lab and MaRS) and got accepted!
The Current State of the Company
This last week of February was the best week the company has had, by far. User activity is way up and the amount of people involved in our project hasn't stopped growing. We are also in the final stretch of closing our financing round, which will allow us to accelerate our growth by a large margin.
However, it's not like it's all good and there is nothing to do now. One of the curses of starting to learn about a topic and making improvements in the way you work is realizing how much there is still to improve.
My company-improvement list on Trello never gets any shorter. Every time I finish a book, I have twenty new improvement ideas and every time I talk to a mentor, I have a dozen more. Even when I finish the implementation of one improvement, I have three more that spawn.
It's very comforting, though, to know that all of the work you put to improve yourself and your startup pays off. Also, realizing that you have created a company that can provide for other human beings is amazing.
I've made a lot of efforts to shed our old prototypical startup way of thinking. This means the following:
There Are Unlimited Vacations for All Employees
This basically means that we don't track anyone's time off. The only time I'm talking to an employee regarding vacation is when I feel they don't take enough time off.
There Are No Working Hours.
If an employee wants to work early morning or late evening, I don't really care (because I do too). As long as the objectives are reasonably met, there is nothing worthwhile to track.
There is No Bragging about the Amount of Work Someone Piles Up Allowed.
It doesn't matter. Only objectives matter. If someone is working an unusual amount of hours, we flag that to the human relations department and we initiate a proposal to find more personnel.
We Invest in Our Employees
We invest in them by buying books, courses, conference tickets, certifications or finding them mentors. Learning is a crucial part of the company's culture and it is heavily promoted. It's also very great for me because I can buy all the books I want on Amazon!
In short, I'm trying to build a company which I would have enjoyed working for. This is one of the guiding principles behind the choices I've made along the way and it really created something that I'm proud of.
My Advice to Aspiring SaaS Entrepreneurs
So that's how I ended up becoming the CTO of my company that has 20+ employees, all from doing random hackathons. It's been a wild ride and still is, but I would not trade this for any other job.
I want to conclude this section with a list of advice and tips for tech entrepreneurs (SaaS in particular) that I've learned along the way. I broke it down into subsections for convenience.
General Product Advice
Your Product is Way Less Important Than You Think
The value the customer can get from your product is what matters. If you can deliver the same amount of value to your customer in a simpler way than having a full blown application, do it.
You will learn faster and you will be able to create more value for your customers in return. At some point though, the only way to keep increasing the value you can deliver is to have a good application. At that point you should have a very good idea about what is important to put in it.
Validate the Need for the Product Before Thinking About a Solution
Spending time and effort on an application that your customers don't care about is the biggest waste of time you can have.
Validate with them every step of the way to see whether or not what you are doing is useful. Even at the expense of development time.
The Tech Stack you Choose is Less Important Than you Think
The most important concern is if you have enough knowledge to build something with the tech you choose, and if you can safely hire people to work with it.
Spending time finding the most optimal stack to work with is oftentimes pointless.
Do not Overcomplicate Your Application at First
Start with a good old monolith and gradually refactor it when needed. The monolith architecture will work like a charm for longer than you think!
Put the Minimum Amount of Features in Your App to Generate the Maximum Amount of Values for Your Customers
The fewer features you have, the less maintenance, fewer bugs, and less technical debt you will accumulate. If a feature is not used by your users, kill it and scrub it from your code base.
Talk to Your Customers
Spend as much time as possible with them and really learn from them. The knowledge you will gain will be a major competitive edge and will allow you to always deliver value to them!
At Some Point CI/CD and a Good Suite of Tests is a Lifesaver.
Not having to fiddle around with deployment and not having to worry as much that you introduced a regression in your code is liberating.
It allows you to become more productive and have a better understanding of the whole code base when you have to read test errors.
Monitoring is Super Important and Should be Implemented as Soon as Possible
Being able to know what is being used, what is the state of the application, and if there are potential problems is a must.
Not having monitoring tools is like driving in a forest road at night with your sunglasses on. It's a bit weird and generally not a safe way to get wherever you want to go.
DO NOT OUTSOURCE YOUR CORE COMPETENCY.
This advice is in all caps because I'm yelling it. If the core of your business is making a web app, make sure that you have everything you need in-house to make a web app.
Relying on outsourcing firms that don't have direct access to your customers or your reality is a sure way to mess the whole thing up. It's therefore extra important that you define clearly what is your core competency in order to not outsource it.
Artificial Intelligence Advice
AI is Great, but Delivering Value to Your Customers is Better
If you don't need AI to deliver value to your customers, don't put AI in what you give them. It will slow you down big time. However, if you validated that you indeed need some sort of AI to provide value to your customers, make that a top priority for your company.
Ensure That You are Collecting the Right Data for Your AI
This is especially important if you are working with partnering organizations as they often have no idea what is good data for a given problem. You need to figure out if the data is great for the problem you are tackling before getting more of it.
Start With a Linear Regression and Work Your Way to That Deep Neural Network with Thousands of Layers
Even if you have tasks for which you have enough data to attempt larger models, start with the simple ones. It will allow for rapid feedback on your data and will help you secure some baseline performance that can be used as benchmarks for the larger models.
Iteratively Improve your AI system and Don't Wait Until Everything is Perfect to Launch.
It's fine to label an AI system as Beta and start experimenting at a larger scale with users. This applies to any product you build, but I feel like this is worth mentioning again in the AI context as it is often forgotten.
Company Advice
Join an Incubator
The amount of coaching you will get – even from the judges before being accepted – is very important. They've seen thousands of startup ideas and they will be able to give you some very valuable advice.
Incubators are oftentimes paid by the government for every startup that they get in their program, which means it's a win-win situation for everyone.
Join an Accelerator After Joining an Incubator
This gives you additional resources and allows you to get very good coaching on very specialized parts of your business (like machine learning or financing). It is also a very good way to network!
Setup Your Core Values and Your Vision for Your Company
Having a vision is like a superpower. As soon as someone throws in that blockchain idea for the nth time you can throw it right back by saying that it doesn't fit the vision.
If someone has a rotten attitude you can easily show your core values publicly and correct course. The hiring and firing is much easier when all of this is setup and understood by the whole company.
Document Your Company's Processes as Soon as Possible
You will be surprised by how much processes you have even at an early stage. You will also be surprised by how little everyone is aware of it (including yourself!).
By documenting these processes you will be in very good shape to start improving and refining them to increase everyone productivity.
You Most Likely Don't Need an Office
If you are building a SaaS product, your stuff will most likely live on the cloud and your offerings will be purely software-based. Learn about how to setup a remote work environment efficiently and save on the office cost early on!
Meetings are Less Important Than You Think
Face to face synchronous meetings are not that useful. I've found that most of the time, just having a Google document that says what problem you want to fix in the meeting and distributing it to people you want to meet with is 99% of the job.
You will get a few comments on what to change, 3-4 asynchronous back-and-forth discussions, and voilà! Another problem fixed.
Meetings are Sometimes Necessary
No meetings whatsoever are not possible, though (I'm a hardcore asynchronous guy and even I need to admit that). If after sending that document you have 30 comments and you get to a stalemate kind of situation, it's usually time to ring the meeting bell and address the point of contention synchronously.
Most of the time, it's a matter of miscommunication. Having this synchronous back and forth allows the issue(s) to be resolved more efficiently.
Make Most Stuff in Your Company Public to All Employees
If something that is work related doesn't have to be private to a specific set of people, it should be public. By having the opportunity to jump in someone else's operational discussion, you can provide much needed feedback that will save lots of time.
Also, by having this whole bank of general knowledge available to everyone, you ensure that people are all aware about what is going on in the other departments.
Make Sure that the Private Stuff Stays Private
This goes both for security-related sensitive material and for private employee matters. If an employee tells you something personal, do not break that trust.
Continuously Improve Your Company's Structure
A company is an ever-growing organism. The structure that is best for today won't necessarily be the best in a month's time. It needs to be continuously tweaked and improved in order to maximize the work that the people working on it can output.
Beware of Working with Large Entities Like Cities, Multinationals, or Governments
These are slow and could end up suffocating your company. They will book meetings upon meetings to move the project forward by inches. Even if they pay you a lot, the cycle of learning you can do with them is so long that you will not have improved by much.
Working with smaller entities allows for more direct feedback. And if you can gather enough of them you can have a much more robust business. Resting on a thousand small pillars is more stable than resting on two huge ones.
Employee Advice:
Don't Hire Jerks Just Because of their Technical Skills
It's a big no-no. If you think about it this way, a person will stifle the productivity of everyone by souring the cultural soup.
If people are dreading going to work because of that one person, you will end up with more problems than what this person can fix with their code.
Cultural Fit is not an Option
Clearly check if the person has the technical abilities that you are looking for. However, check just as rigorously if the person as the right personality for your company.
Having someone clash with the company or not upholding one of your core values will do more harm than good.
Team Fit is not an Option
Make the teams an integral part of the hiring process. You will be surprised by how picky the team is and how rigorous they are in the hiring process.
It happened quite often that the person we were interviewing passed the technical interview and the cultural one, but didn't pass the team interview.
The rationale for rejecting a participant from the team was always valid and we couldn't believe we didn't catch it earlier in the process.
Neurodiversity Increases Productivity
You have to resist the urge to hire people that think exactly like you if you want to have a truly productive company.
By having people from different backgrounds, you will increase the chance of finding creative ways out of problems and you will reduce your blind spots by a lot.
Don't Try to Fit a Good Profile in the Company, Find a Good Profile for a Need
Always start by assessing what is your most urgent need and then find the best person to fill that position. By starting the other way, you will bloat your company with people that don't truly create value.
You Will Have to Fire People and it's for the Best
I've had to let a few people in the company go, and every time it was better for all parties. However, do it with respect. If you did all the work to bring someone on your ship, you should do all the work to bring someone out of it.
This means ensuring that this person understands why it's not a fit, that you gave enough warning signs, and making sure that this person has the support they need once they are moving away from the company.
Make Sure That Your Employees are Genuinely Happy
If someone doesn't feel good, talk to them and help them out. Wish them a happy birthday. Say thank you when they do something great. Coach them when they want to grow. Debug them when they make a mistake.
Having happy employees is one of your most valuable currencies as a startup and what makes working in one such a great experience.
Personal Advice:
Make Sure that the Founders or Executives don't Kill Each Other – and the Company
What do you get when you have a toxic startup culture of working insane work hours coupled with financial stress and customer problems? A good recipe for company failure.
Make sure to always reserve at least one hour per week where you don't talk about the company, but just check on each other and try to mend personal issues in the open.
Repeat After me: It's 👏 a 👏 Marathon 👏 not 👏 a 👏 Sprint
Insane working conditions cannot last. It's not if you will burn out, it's when.
If you cannot envision keeping the pace of work you currently have for the rest of your life, change it before it's too late.
I've seen too many startups crumble suddenly because of people thinking they can sustain having no time off forever.
Leave Room for Your Personal Growth
Learn about that one topic that is completely left field for your startup and enjoy it. Go ahead and network with people for your own benefit, it's okay. The more you grow as a person the higher the potential growth for your company.
Leave Room to Just Chill Out
Even if you enjoy working on your startup don't neglect the other aspects of your life.
It's fine to have other friends outside of work and it's fine to just unplug for a while. If you can't do that you have serious issue to fix in your company.
Have Fun
It's genuinely fun to build a company from the ground up. Enjoy the time working on that nasty bug that put the whole EC2 instance down. Enjoy your time calling this one customer that has nothing good to say about what you do.
Enjoy all of the little problems that will pave the way of your company. Because a startup can only do two thing: Die, in which case you will look back at those days with fond memory. Grow, in which case it will start to become something bigger than you and gain a personality of its own!
Useful (SaaS) Entrepreneurship Reading
The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses:
This book is a very simple read and taught me that cycling through hypothesis/learning is way more important than doing the most perfect thing right off the bat.
As a technical person that loves technology, I couldn’t understand why the tech was not at the forefront of every business discussion.
This book, with the clear example of bold tests that were done with real users, showed me exactly why a focus on building a product before understanding what the users will think of the product is a bad idea.
Traction: Get a Grip on Your Business
This book helped me make sense of how to structure our company once it has scaled past the founders. I’m at something like the sixth read cover to cover.
There is a lot of useful information and practical guidelines to use in order to really get a solid structure that make sense for the next growth phase.
It also helped create a sense of calm when thinking about the future because it increases your awareness of what will come in the future.
Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World with OKRs
I read this book before reading Traction, however there are a lot of similarities between the OKR goal structure and the Rock goal structure from Traction. The basic idea is that you have limited time to work on goals/projects, so work on the most impactful ones and ditch the rest.
The idea of simply not thinking about the low priority objectives really creates a sense of space in your head. Knowing exactly what to focus on and having the liberty to think about how to get there also helped create an ultra-collaborative structure.
I use the OKR system in my personal life too. It really helps me reassure myself that I’m on the right path and allow me to say no to opportunities that pop up throughout year that are not aligned with my objectives.
Peopleware: Productive Projects and Teams
This was a very enjoyable read. It talks about a facet of software engineering that is often not taken into consideration, which is the people factor. I absolutely love the straight to the point organic writing style that the authors use.
Lots of examples are given and there is a significant supplementation of statistics along their argumentation that really help gauge what non conventional changes to implement.
DRIVE: The surprising truth about what motivates us
Drive is very closely related to Peopleware in the subject it addresses. Both of them help in figuring out how to create a work environment that is purposeful and that drive people to give their fullest.
I’ve learned a great deal about how much “carrot and stick” kind of reward/punishment comes into play in the traditional workplace and how it's not the optimal way to increase motivation.
It also allowed me to understand how I can push myself to accomplish my goals in a purposeful manner without having to bribe and trick myself.
Effective DevOps: Building a Culture of Collaboration, Affinity, and Tooling at Scale
This book is an extensive introduction to DevOps culture and is a good handbook to keep to consult when you're unsure about a certain aspect or situation.
It was the book that introduced me in more depth to that way of thinking and got me to really understand it more than on the surface level. It had some very neat examples of how all of the DevOps concepts tie up in the real world.
However, it’s quite a lengthy book. It is meant to be consulted in a non-linear fashion. I recommend keeping a copy at hand if you manage a technological team to get some ideas about what to do in a given situation.
The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win
I read the Phoenix Project a while after having read Effective DevOps. Effective DevOps gave me a deeper understanding of the movement, but it’s the Phoenix Project that really made everything “click”.
It’s a novel, but explained in such an organic way that it could have been a biography. I read the whole thing in 2 days over the summer as I was very engaged with the protagonist's struggle with inefficient process and “impossible” goals to meet.
After reading it I felt way more confident that the changes I was making to my organization were the right ones.
If I had one book to give to a non-tech manager to make them understand how to make a tech department fail and how to make it thrive, it would be this one.
Designing Data-Intensive Applications
This book was so densely packed with information gained from working with very difficult problems that you probably need to re-read it from time to time while you also work on difficult problems.
I’ve learned a lot, both in the inner design of the behemoth of the internet and how much these behemoths were built by facing a constant stream of problems.
The sheer amount of tradeoffs, learning, and ambiguity that takes place in systems at huge scale was staggering. It helped me prepare and better react when I hit various problems in my tiny (in comparison) systems I’d been building.
Likewise, this is the kind of book that should be read periodically while building something that is in the process of scaling.
Forge Your Future with Open Source: Build Your Skills. Build Your Network. Build the Future of Technology
This book is one that really helped me better structure our remote company so we could hit our business objectives and help our employees feel productive and happy.
I drew a lot of inspiration from how open source projects were structured and made quite a lot of changes in that sense. It also helped me understand and appreciate a bit more about how open source projects work.
Principles by Ray Dalio
This is an incredible book with an insane amount of tips from a successful entrepreneur in the financial sector.
The amount of useful content in there is staggering and will require multiple reads in order to extract it all. If you are looking for new ideas to make your organization more efficient, better at problem solving, or stimulate growth, it's a must!
Delivering Happiness: A Path to Profits, Passion, and Purpose
A very beautiful book by the late CEO of Zappos. It's a humble book filled with good learning and takeaways by Tony Hsieh in his entrepreneurial journey.
The most important part here is the focus on making sure that the culture was right, as he had two main company successes in his career: One with LinkExchange that had no focus on the culture and another one with Zappos which was heavily invested in it.
The latter is arguably the stronger business.
Reaching Out
If you are interested in learning more about my company, you can check our website. If you have questions feel free to add me on LinkedIn or Twitter to chat :)
I hope this was helpful!