---
title: "Neeto: BigBinary's Engineering Prowess"
description: "How Neeto demonstrates BigBinary's engineering capabilities."
canonical_url: "https://www.bigbinary.com/neeto-proof-of-bigbinarys-engineering-prowess"
markdown_url: "https://www.bigbinary.com/neeto-proof-of-bigbinarys-engineering-prowess.md"
---

# Neeto: BigBinary's Engineering Prowess

How Neeto demonstrates BigBinary's engineering capabilities.

[Neeto](https://neeto.com/) 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.

## Links

- [Human page](https://www.bigbinary.com/neeto-proof-of-bigbinarys-engineering-prowess)