Notes from a CTO #5: Learning from past, my toolbox, Rajesh dai & memes
How would I have done things differently, if I had to restart Docsumo today.
Hey, it’s Bkrm from Docsumo.
You’re reading the fifth issue of Notes from a CTO: my raw canvas of thoughts and collection of interesting resources I found online. My goal here is to spread knowledge at scale. If this is up your alley, have a read and let me know what you think!
1. Running a startup
This section is a dump of the various facets of startups I have experienced while running one. This week, let's discuss what I would do differently if I had to start Docsumo today.
A similar question was raised by my team last week, and since then I have been tinkering with this. So I thought, I will talk about this today with a slight focus on the tech side of things.
Choosing an Idea: You are free to choose an idea but remember you'll also bear the consequences. On the idea side, I don't think we would pivot. It's true we could have chosen a less complex problem to solve, but I feel the time and technology are right to disrupt the Document AI space. A lot of great things are happening. An example, our intern trained an API in 1 hour, which would take months for two engineers. If you look deep enough, most problems are similar in nature, and they need a good product, marketing, and distribution to solve them. (Which isn't easy to build, BTW)
Hiring: I have always been lucky with hiring. But one thing I would have done early on was hired more managers and project owners, maybe after six months of operations. We hired our first project manager six months ago and our engineering manager two months ago. These positions are essential as you scale, and you should fill them ASAP so that the founders can spend more time exploring other markets and strategies. Building a great team and product requires different sets of people during the startup's life cycle. Some people you hired early on might not be a good fit for the long run if they don't upskill themselves.
Be less of an Engineer: Most engineers like to be in control and enjoy complexity. But customers don't care about complex problems, rather they only care about trying a solution that is easy to use. So don't add features thinking it will attract customers because, in my experience, the opposite is true. There are no barriers to entry if you're developing a product. Read this tweet thread by Hemant Mohapatra. You can assemble a team, and deploy complex solutions in the cloud, but what you can't replicate is the product experience, marketing, and distribution. These are the real moats, not the complexity of a technology
2. Technology
Let's get right into the technical stuff and talk about what I would do differently.
Tech stack: We as a company are focused on AI, so we have a large code base on pandas, but pandas data frames are the worst data structure to put in production. They are good to experiment with, but once the experiment is complete, always convert them to dict and tuples. You can even use custom types using data class or any other method.
Run everything on Container and K8s from day 1. I know people have different opinions, but when done right, it can save you a lot of pain in the long run. Read my fourth newsletter to get more details.
Security posture: This should be ingrained in your tech stack when you start. Your focus should be on- using fewer permission Iam roles, MR request best practices, pre-commit hooks, and static/dynamic code scans like sonarqube and slscan.
App architecture: We made a big blunder when we started, as we based the architecture of the app on a single user. This incident still haunts the product team. Please take your time to think about features and make at least a skeleton for a technical and functional PRD before you start your projects. This habit will capture your thoughts in one place. It is true that you don't need to have a complete PRD when you are starting. Many things in your PRD will be useless, but making the bare minimum will help you be more organized and allow you to incorporate customer feedback quickly when your hypothesis fails. There is no right or wrong answer, as it's all about learning from every step.
3. Podcasts
Blast from the past. I rewatched this podcast this week because there are 2 things that resonate with me:
1. Self-motivation and Self-discipline. It's not just motivation and discipline, the “Self” part is always more important.
2. Always think positively. Even when his oxygen tank was stolen at 7000 ft, he was happy that it would have saved someone's life. Always give the benefit of doubt to other people's actions. 90% of the problems in our lives are created by our own thinking. The only thing that matters is being happy and doing what you love. The rest is secondary.
4. Interesting links
Repos:
My toolbox editions
Espanso: Text expander I can’t live without. The amount of hours it has saved me is tremendous.
Excalidraw: It’s a pretty good tool to brainstorm, make diagrams, or just have fun. I prefer the web version of this as everything is end-to-end encrypted.
Logseq: Taking notes is essential if you want to be more organized, couple this with its plugin ecosystem, and it’s a must-have for everyone
For more follow me on Github: bkrmdahal
Articles:
Docker went from $11M to $135M in 2 years: I love a redemption story: you know when everyone assumes you have lost, but then you turn it around? This turnaround takes a lot of courage. Am I a fan of all their decision? No, but I respect their rationale for doing anything to survive.
A founder who sold her company to JP Morgan for $175 million allegedly paid a college professor $18K to fabricate 4 million accounts: I hope it was this easy to add these 4 million accounts. 😂 One sin will lead you right into a spiral of committing many more of them.
Tech debt PayDay: We have also started to use the 80:20 rule to manage the tech debt at Docsumo. 80% of the sprint is for adding new features, and 20% is for tech debt and site reliability.
The Art of Knowing When to Quit: This skill is essential as it will help you differentiate between when you should stop beating a dead horse and when to shut up and grind it out. Finding the right balance is easier said than done.
Python disappointing superpowers: I love python for its simplicity. The article, "Python community cares about solving problems and not about how clever your code is" resonated with me. Acting clever without substance is stupid. Problem-solving is the real deal, so projects and libraries that solve problems don't brag about their clever code, but rather focus on the problem at hand
5. Quotes/ Books
Book recommendation: Harry Potter
This week I realized I have not read books that made me happy. My advice rest, read fiction. Life is too short
Success is not delivering a feature; success is learning how to solve the customer's problem
- Eric Ries (The Lean Startup)
As an engineer, changing my mindset was very difficult. When we hire, we ensure to cultivate these things very early. We love to build things, which offer us great satisfaction. This idea should change, and we should become more customer obsessed. Customer>anything else, and this is the mindset all engineers should have when picking a ticket.
Our Slack channels have a great collection of memes.
Can we get your “rocket to the moon” driving license?
*For the audience outside of Nepal, Rajesh Hamal is the Chuck Norris of Nepal. One day before, we built a model to extract information from a Nepali driving license and we showed it at the LOCUS event. This is how fast things go into production at Docsumo.
That’s it for this edition, I hope you find it useful.
P.S. Taking a 2-week break, so see you in four weeks!
Best,
Bikram Dahal
P.S. If you learned something new today, please share “Notes from a CTO” with your friends and spread the love. ✌🏻
Need more "Rajesh dai x Docsumo" photos. Lol
Always fun to read. Does Docsumo has office in Banglore, would love to work at docsumo as I am actively looking for AI roles.