At Neeto, we are building a lot of products. Let's have a look at what these products are.
We have a Google sheet named Neeto products and people. Here is how it looked when this blog was published.
In a later blog, we will discuss why we are building so many products without ensuring the success of even a single product. This blog is all about what we are building at Neeto. We would look at the “products” part of “Neeto products and people”.
In the previous article, we mentioned that at BigBinary, we were already using AceInvoice for time tracking and invoicing. We didn’t want to add any new features to AceInvoice, so we decided to build nitroHelp and nitroForm. NitroHelp has three main features: chat, email-based ticketing, and a knowledge base. After a few months of development, it became clear to us that nitroHelp should be broken into three different products. There was minimal commonality between the three different features, and one look at the codebase made that very clear. We had folders like “chat,” “desk,” and “KB” everywhere. We had to namespace a lot of models because common model names were taken, and the unit tests took longer to run. We had to run the whole test suite even though something had only changed in the KB area.
While splitting nitroHelp, we changed the name from “nitro” to “Neeto”. So now we had NeetoChat, NeetoDesk, and NeetoKB.
Soon, we realized that users were not going to log into each of the products separately. So now we needed a single sign-on mechanism, and hence we built NeetoAuth. NeetoAuth is not a product that others can use. It’s an internal tool that manages authentication for all the neeto products.
nitroForm was also renamed to NeetoForm. Working on NeetoForm proved to be a lot more challenging than we had earlier estimated. NeetoForm has a lot of surface area, and we needed to cover significant ground. In the beginning, NeetoForm supported both the “card style” and the “long form” style. This created many design challenges. It also created engineering complexities, and we kept running into edge cases.
Finally, after months of setbacks, we decided to remove the support for “card style.”This immediately helped us deliver features at a faster pace and with more stability. At this time, NeetoForm is relatively stable, and our clients are happy using it.
As we were building new features,, we needed a way to let our users know about the new features that were being delivered. After some deliberations, we started working on NeetoChangelog. Currently, NeetoChangelog is working great. In fact, if you sign up for any of the neeto products, you can click on “what’s new” to see NeetoChangelog in action.
As we started building more products, we needed to worry about what the UI would look like. Some folks in the company knew Figma, so we had a couple of sessions with them to learn Figma. Folks also tried to learn Figma from online resources. We found the learning curve for Figma to be very high for our engineers. This is not a knock against Figma. Folks who are familiar with Figma love it, and it's a great product. What we needed was a low-fidelity way of discussing what the interface would look like. Unlike professional UX folks, our goal was not to create a pixel-perfect design but to have a rough sketch of the UI.
After some deliberations, we decided to work on a POC to build a wireframing solution, and thus NeetoWireframe came to life.
So far, we have been discussing product features, execution, deployment, etc, in Github issues. This meant that Github issues became very noisy. We decided to use GitHub only for the actual issues and not for the product feature discussion. After trying out a few products for the product discussion, we settled on building NeetoPlanner.
Sometime back, we started working with an organization that deals with mental health-related issues. They have more than 500 counselors on their platform. Deciding which patient would see which counselor was being done using a large Excel file. We started building NeetoCal in a rush, and in a short span of time, we got it working. We also got Stripe payment working with NeetoCal. Our client successfully receives payments anytime a booking is made.
We have been using AceInvoice for a few years for time tracking and invoicing. At this time, we had more than ten Neeto products under development. We decided to migrate AceInvoice to NeetoInvoice so that we would have a consistent set of code to maintain. Migrations are always tricky. After months and months of work, we were ready, and then, one day we migrated all the users and their data from AceInvoice to NeetoInvoice. We did get a handful of issues from our customers, but overall, it was a very smooth experience.
In the meantime, the time had come to conduct interviews with the folks in college for the following recruiting season. More than 600 folks responded to our call for the BigBinary off-campus interview. We checked with the existing vendors who provide technical assessment services, and the cost was coming up to be more than $20,000. So, we decided to build NeetoRunner. NeetoRunner would be a “code assessment” tool.
It was an extremely high-pressure project since we had only a few weeks to build it. We built it, and it worked almost. We didn’t do any stress testing, and when more than 600 people started using NeetoRunner at the same time, then the database began to run out of connections. While the assessment was going on, we had to upgrade the database plan on Heroku to get more connections. Other than that, everything else worked fine, and NeetoRunner proved to be a winner.
As the products started maturing, we needed to do a better job of testing them, and thus, we formed a “QA team.” We started using third-party tools to manage “test cases”. However, we found these tools to be extremely expensive. Since these tools charge per user, we couldn’t give access to developers who don’t need to see test cases very often. We decided to build NeetoTestify. Next week, we will be migrating all the test cases from the third-party tool to NeetoTestify, and we are very excited about it.
In August 2022, Heroku announced that free dynos would go away. We have been using Heroku review apps for all our products, and this change in plan has increased our costs significantly since we are building so many products. In the future, we plan to add even more products. It means our Heroku cost will keep going up linearly.
We decided to do a quick POC to see if we can spin up something just to build the review apps for the pull requests. We named this product NeetoReview. The POC worked, and slowly we migrated to NeetoReview for the generation of all the review apps for all the Neeto products. This was done by the end of Nov 2022. In a span of 9 weeks, we had gone from a mere idea to a complete migration off of Heroku.
NeetoReview kept getting better, and in Feb 2023, we migrated all the staging applications of all the Neeto products from Heroku to NeetoReview. Well, now NeetoReview can be used for things other than just “review apps.” So, we changed the name from NeetoReview to NeetoDeploy.
NeetoDeploy is shaping up to be a good Heroku alternative. As of this writing, Heroku is still serving all production instances. BigBinary is primarily a Ruby on Rails and React consulting company. So, building NeetoDeploy was out of our comfort zone as it involved a lot of DevOps and Kubernetes skills. In the coming weeks and months, we will be discussing how we are building this Heroku alternative.
While we were building NeetoChat, we wondered why we needed to ask the users what they needed help with. We know that no one wants to chat with a support agent. People contact support agents because they feel stuck. We thought if we could somehow see what the user was doing just before clicking on the “chat icon,” that would give us a glimpse into what the user wanted to do but could not do.
That desire to see what the user was doing before contacting the support agent led us down the path of recording users’ sessions while they were online. This resulted in a new neeto product called NeetoReplay. Using NeetoReplay now, any website or web product owner can see what the users are doing on their site. NeetoReplay has proved to be an immensely useful tool in fixing issues we didn’t even know existed.
Monitoring the health of our APIs and workers is essential. We are building NeetoMonitor to do that.
NeetoSite is being built so that we can build simple websites without too much complexity.
As the name suggests, NeetoQuiz is for building quizzes, and NeetoCRM is for CRM.
NeetoSocial is a tool we are building to provide “social media analytics” and reporting.
While building NeetoDeploy, we gained experience in handling Kubernetes. Leveraging that experience, we jumped in on building NeetoCI to run our unit and cypress tests. Running Cypress tests is proving to be very expensive, and we hope that switching to NeetoCI will cost us a lot less.
If you made it all the way to the end of this blog, you might be wondering why Neeto is building all these products and why Neeto is building business tools (NeetoChat) and developer tools (NeetoDeploy). Why build all these products without ensuring the success of even a single product? These are all good questions that we have asked ourselves many times. Next week, we will try to answer these questions.
Currently, only the top six products, namely NeetoChat, NeetoDesk, NeetoKB, NeetoForm, NeetoInvoice, and NeetoCal, are available for public use. However, if you are very interested in being an early user of any other Neeto product, please post a comment to this blog, tweet to us, or email [email protected].