Neeto is what happens when strong engineering meets relentless curiosity.
Neeto is our playground. It’s where we experiment, learn new technologies, and push our limits. We wanted to understand how Heroku works, so we built a Heroku alternative: NeetoDeploy. Today, every Neeto product runs on NeetoDeploy.
As a fully remote company, we were heavy users of Loom. We loved everything about it—except the pricing. We couldn’t justify giving Loom to every engineer. So we built a quick proof of concept. It worked, we kept going, and NeetoRecord was born. Today, NeetoRecord is used by hundreds of companies worldwide.
The same story repeated with Calendly. We used it for scheduling calls with clients and customers and loved the product—but not the cost. So we built NeetoCal, a Calendly alternative. It worked too. Now, every month, more than 50,000 bookings are scheduled through NeetoCal by customers across the world.
As Neeto products gained more users, we needed better tools to support them. We built our own chat software, NeetoChat, and our own ticketing system, NeetoDesk, to manage customer conversations and support requests.
Building 10+ products at the same time creates its own engineering challenges. The only way to maintain this many products is to ruthlessly prioritize code sharing. Anything used by more than one product is converted into an internal gem or engine so the code can be shared across the Neeto ecosystem.
That led to a new challenge: what happens when one of these internal gems is upgraded? To handle that, we built our own internal compliance system to track and manage upgrades safely across all products.
As we built more products, we opened more pull requests and ran more test suites. Running all those tests on GitHub Actions started to get expensive. So we asked ourselves: how hard would it be to build a CI system? We experimented, and NeetoCI was the result. Today, all our CI tests run on NeetoCI.
We needed a FAQ system so customers wouldn’t have to ask the same questions again and again—so we built NeetoKB. To keep track of which customers requested which features, we built NeetoEngage. To have full control over the look, feel, and URLs of our blogs, we built NeetoPublish.
At some point, we started using Cursor Bugbot to catch issues in pull requests. Cursor was great but again, too expensive, and Yedhin was passionate about building our own alternative. That spark became NeetoBugWatch. Varun had a similar spark for better visibility into Playwright tests, which led to NeetoPlaydash. For project management, we built NeetoPlanner.
You can see the engineering pattern: it’s not a neat, carefully planned roadmap. It’s a series of sparks. When someone on the team is excited to build something, we give it space. We start with a proof-of-concept and see where it goes.
We’re not afraid to bet on unfamiliar technologies. We had no idea how to build a Heroku alternative (NeetoDeploy), a Cursor bot alternative (NeetoBugWatch), a GitHub Actions alternative (NeetoCI), or a Loom alternative (NeetoRecord) when we started. We figured it out as we built.
That bias toward building—backed by solid engineering—makes BigBinary an extraordinary place to work and an exceptional partner to build with.
All Neeto products are built using Ruby on Rails, Redis, Sidekiq, React.js and PostgreSQL.