First of all, why am I a solo founder?
Wait, who am I? I am the founder and CEO of ToolJet ( https://github.com/ToolJet/ToolJet / ) - an open-source low-code startup.
Every solo technical founder goes through this confusion - should I bring in a non-technical co-founder and take care of product/engineering or should I focus more on the business and bring in another technical co-founder.
It was a sudden decision to start working full-time on the idea that I’ve had in my mind for quite some time. I chose to be a solo founder for these reasons:
ToolJet is a developer tool and thus finding a non-technical co-founder ( as per the tradition ) is not easy. Alignment of a tech person and non-tech person in building something for developers is not easy.
I am a developer and having two technical founders will lead to too many discussions and the time to launch will be affected. Yeah, having two minds brainstorming on something results in a better product but in my case I needed to optimise for time just because the runway was very short.
Why will someone quit their full-time job to become your co-founder? For someone without a lot of success stories to say, no one is gonna quit their job and start working on your idea full-time without salary as a co-founder.
There were still some good folks who I wanted as co-founders. They were simply not in a position to commit to a startup at the time.
And it turned out well!
The pros
Launched the product in 2 months. Obviously there were many engineering decisions that were less than ideal but time to market is also an equally important factor.
No co-founder conflicts. There are countless stories where startups fail not because of lack of revenue/capital but purely because of the conflicts between founders. Two ( or more ) people working on same startup might have their own vision for the product/company in later stages. This always isn’t true but happens more often than you think.
The elephant in the room: more ownership in the company. This is a pro but you should never go solo solely for this reason. 100% of zero still is zero 😇.
What did I miss?
a) No one to review your code or features. This probably resulted in less than ideal architecture decisions. On the bright side, you were able to launch the product quickly. If the launch was a success and if you were able to get customers or funding, you can always hire smarter folks to redesign the architecture. Many people won’t agree to this redesign as it is a lot of efforts. We had done it and it was totally worth it. You can read that story here: https://blog.tooljet.com/migrating-toojet-from-ruby-on-rails-to-nodejs/.
b) No one to share your tasks. Building a company involves a lot more than coding. There are many time consuming tasks such as legal compliance, fundraising, payroll management, hiring, etc. Having two or more founders is a bliss when it comes to this. But there is a solution, continue reading.
c) Some VCs don’t like solo founder startups. This point is just from my personal experience talking to a few VC firms & angels before the public launch of ToolJet. They are partially right because they don’t see someone in the team who can do the sales. Also this might not be true for other geographies and investors focused on developer tools. Since I didn’t have any experience in fundraising, I reached out to every VC or angel I came across 😁.
d) You are the solo decision maker for everything. Which means there isn’t anyone to point out your mistakes, comes up with new ideas or brainstorm and improve your ideas. Having the technical skills to build the product is just not enough to make a decision on the future of company.
How did I manage this situation at ToolJet?
First of all, you need to come to a conclusion if you want to drive the engineering team or the company. It is not humanely possible to handle both in my opinion. You will not have enough time and it is not easy to switch between very different contexts.
ToolJet was fortunate enough to close a seed round within two weeks of its launch. Fundraise was all about talking to a lot of people. Product development during this period will just stop if you are a solo founder. For this reason, I was optimising fundraise for speed right partners and not for higher valuations.
Right after the fundraise, the focus was to build a team of senior engineers. The criteria was simple, we did not care about the experience in Node.js or opens-source. We wanted engineers who have built something of their own in the past. My focus then was to offload majority of the engineering tasks and decisions to these smarter folks. Once they were upto speed, we started hiring more engineers who were managed by the core team. I had less visibility into the daily activities of these new engineers by design.
This process was slow as we were very picky about hiring engineers. It went really well and the green boxes on my GitHub profile started to get lighter:
2021
2022
This chart reminds me of the charts generated by those defragmenting softwares on older versions of Windows.
Well, both the charts explain the same - freeing up space for something else.
At the time of writing this, my inputs to decisions in engineering is very less. The engineering team takes care of everything. And thus the solo technical founder became non-technical founder in an year 😇
Do I miss coding? obviously! but since we built a team of smarter engineers, the best thing I can do is to not code 😅.
Streamlining the engineering activities
At this point of time, we had a few engineers and streamlining the activities of engineering team became a bottleneck for me. The engineering team had only 10 members in total but the amount of features/fixes/improvements that they push for every release was too much. It requires constant inputs from me for assigning and signing off the tasks.
I was looking for someone who can take the ownership of product since the closing of our seed round. Our assumption was that this person will have the role of head of engineering or head of product or both. We interviewed great candidates referred by friends, colleagues and investors.
We finally found someone who had had experience bootstrapping a SaaS business, has strong engineering and product background. Shubham joined our team as the head of product in June 2022.
Now the engineering team is managed by Shubham and I can focus more on the business.
The framework
Here is the set of decisions that helped me reduce the dependency of engineering team one myself and eventually almost completely removing the dependencies:
First few hires should be folks who have built products in past or folks who wants to build their own products in the future. Hire as if you expect yourself to be offline for a month and these folks have to run the engineering team.
Focus on offloading your tasks and let them make the decisions. Trust the team ( after all you hired them ), give feedback and suggestions but never decide stuffs yourself.
Code reviews should also be offloaded. In the initial days, let them know if there are any suggestions to improve but do not nitpick - every fight is not worth picking.
When streamlining the product management becomes a bottleneck, look for someone who can take the ownership of the product. This person should own the prioritisation, definition and delivery of product features and improvements.
What’s next?
Free up more time!
Our next focus is to build a product team who can own different areas of the product. Since there are multiple teams right now, a team is necessary to streamline the development efforts.
What will I be doing? My focus will be build a sustainable company with great work culture! that mostly translates into meeting customers, working with product team to set the future of product and hiring more & more talented people.
Will we hire someone as a co-founder? nope! but if someone from the team steps up and adds a lot of value that is expected from a co-founder, we will definitely promote the person as a co-founder. It still is too early for ToolJet and there is a lot more to do, learn and improve/adapt.
That’s the end of the story for now.
> I needed to optimise for time just because the runway was very short.
i like the "runway" analogy, wondering what are some assessments you have to frame this.
A "solo founder" should be too busy with real work to be writing articles like this.