Founded by former Uber engineers Naomi Chopra and Haritabh Singh, Hatica was incubated at the Accel Founderstack Program in 2020. A SaaS-based engineering platform, Hatica, was formed with the intent to measure the productivity of developers and help them with better time management since the pandemic forced many businesses to shift to remote working.
In January this year, Hatica raised USD 900,000 in its pre-seed funding round led by Kae Capital, followed by Titan Capital, iSeed Ventures and angel investor GBS Bindra. Chopra stated then that the company’s system was still in the beta stage and is expected to be released in the market by the first quarter of this year. We spoke to him about what Hatica’s tech stack looks like, and the lessons learnt along the way.
AIM: What is the tech stack that Hatica is using? What are the details of its stack share?
Naomi Chopra: Hatica is built using Typescript and Golang mostly. Its front-end is built on React, while the backend is a set of microservices in Node and Golang running on Kubernetes along with Temporal for orchestration and Hasura as the data access layer. Its data stack is built on Postgres, Clickhouse and Elasticsearch.
Sign up for your weekly dose of what's up in emerging technology.
AIM: How did you decide your stack share? What are the factors that you considered in the decision-making?
Naomi Chopra: The factors that went into deciding our tech stack were a combination of the founders’ expertise and the availability of talent, along with the most important factor of all, which was essentially how suited the stack was for an I/O and data-intensive system like ours.
Our factors were skewed towards our expertise when we were just starting out, but as we grew, our decision revolved around choosing the best stack for the solution while ensuring access to talent and support by the community.
AIM: Has Hatica been using the same tech stack since 2019? If not, then what were the reasons for migrating to a different tech stack?
As we gained traction and started growing rapidly, we migrated to using Golang for some services along with a more scalable architecture powered by Temporal for microservices orchestration and Clickhouse for serving analytical queries. All of this is now hosted on Kubernetes clusters.
AIM: How did Hatica go about the migration process? Was it costly to migrate?
Naomi Chopra: Migration was costly in terms of both time and effort, but only in the short run. The long term benefits of a more scalable and robust architecture have served us well as we grow rapidly in customer base.
AIM: What were the hiccups that you or your users faced during the migration? How did you smoothen the tech issues during this time?
Naomi Chopra: One hiccup we faced during migration was the fact that our authorisation layer, which decided what can be accessed by whom, became too complex since we had to support two different sets of APIs and data access layers, both old and new, till we migrated fully. We solved that by first completing our unit testing suite for the data access layer so as to prevent access permissions issues from going into production.
AIM: How do you think Hatica’s tech journey has evolved since its inception?
Naomi Chopra: Hatica started out as a set of dashboards for engineering managers with little to no customisation available to them. As we gained traction, we needed to provide configurability that would help our product support different types of engineering workflows. This was the first milestone when we started rebuilding many of our microservices. But the larger change came as we scaled up in traffic in a very short period of time as we started onboarding large teams. This led us to evolve our overall data stack, which has been a considerable effort. Fortunately, we adopted some key best practices from day one, which helped us migrate systems component by component with very little downtime.
AIM: What are some of the most valuable lessons you learnt that you would like to share with other budding startups?
Naomi Chopra: Don’t choose a stack to solve for the next million users; pick something you can make a prototype with quickly. Play to your strengths, even though there could be other tools more appropriate for the problem; for example, pick a programming language that you are good at and just works for your solution, rather than picking a cool new language.
Pick a stack for which you can find talent easily. There is, anyway, a lot of competition for hiring engineering talent, don’t make it harder by picking a shiny new tool that is hard to learn, at least not when you are just starting out.
Don’t reinvent the wheel. Try to look for a robust open-source solution when implementing a component or a service. If it doesn’t solve your problem wholly, try to extend it instead of implementing a solution from scratch.
There are some basic, foundational concepts and best practices you should surely start with, like using unique IDs like UUIDs for most resources. Such best practices are easy to adopt from the beginning and hard to migrate to.
Document your systems by adopting practices like writing RFCs. They not only drive collaboration and effective reviews resulting in robust decision making, but also automatically result in good documentation, which is essential not just to onboarding your new teammates but also for founders and early engineers to recall specs and decisions.
Use infra-as-code, like using Terraform. It’s simpler than it looks and gets you quickly up and running by utilising open-source packages.