BigBinary Logo

World-class Rails engineers, proven in production.

Anyone can say they are experts. Our engineers designed, built and run Neeto: more than 20 SaaS products on Ruby on Rails, used every day by paying customers. When you work with BigBinary, these are the engineers who work on your product.

Talk to usSee the hard problems we solved

Code our engineers wrote is running in production and has already handled real scale.

0M+Bookings on NeetoCal
0K+Screen recordings
0+Payment transactions
$0.0M+Collected, in US dollars
Only Rails

We don't just advise on Rails. We run it.

For 14+ years BigBinary has done one thing: Ruby on Rails. Building Neeto put our engineers on the hook for everything a product team faces: scale, uptime, security, cloud bills and customers who expect it to just work. That is experience you can't get from client projects alone.

Owners, not ticket-takers

Our engineers own products end to end, from the database schema to the deploy pipeline to the 2 a.m. incident. They bring that ownership to your codebase.

Deep in Rails internals

Postgres constraints, background jobs, Action Cable, Rails engines, safe migrations. Our team works at the level where Rails meets the database and the infrastructure.

Battle-tested patterns

Every pattern we recommend has been proven across 20+ live products. You get answers that work in production, not theories.

The Neeto platform

One Rails platform. 20+ products.

Building one SaaS product is hard. Our engineers built a platform that lets a small team ship and run more than twenty.

Shared Rails engines

Payments, webhooks, integrations, rules, Slack, WhatsApp, themes, SEO and access control are each a Rails engine. One fix in the payments engine ships to every product that takes money.

Always on the latest Rails

NeetoCal runs Rails 8.1 on Ruby 4.0. Keeping 20+ apps current is routine work for our engineers, and they bring that upgrade experience to your app.

Our own tools, built in Rails

We deploy on NeetoDeploy, test on NeetoCI, track errors with NeetoBugWatch and review browser tests in NeetoPlaydash. All built and run by our team.

NeetoCal's Gemfile

35 Neeto gems, 28 of them Rails engines

paymentsintegrationswebhooksaccess-controlactivitiesapi-keyscrmcustom-domainsdata-opseditoremail-deliveryfiltersformnotificationsrulesseoslackteam-membersthemeswhatsapp…and more

Built on it: NeetoCal, NeetoDesk, NeetoForm, NeetoRecord, NeetoChat, NeetoInvoice, NeetoKB, NeetoCRM, NeetoSite, NeetoSign, NeetoCourse, NeetoQuiz, NeetoPlanner, NeetoPeople, NeetoEngage and more.

Hard problems, solved

Problems that show how our engineers think.

Every detail below comes from Neeto's production code.

Concurrency · NeetoCal

Two people, one slot. Only one booking.

With over a million bookings, two visitors clicking the same slot within milliseconds is a daily event. A check in Ruby can't win that race, and with paid bookings the card may already be charged.

  • The database refuses it. Our engineers added a PostgreSQL exclusion constraint on time ranges, so no code path, job or console session can ever create a double booking.
  • Even the deadlock is handled. Two inserts can deadlock while Postgres checks the constraint. NeetoCal recognises that exact case and shows the visitor a clean "slot just got taken" message.
  • Paid but lost the race. The customer gets 10 hours to pick a new time, then an automatic, idempotent refund.
  • Row locks where they matter. Group seats, discount-code limits and saved-card charges never oversell.

What you getEngineers who push correctness into the database, where races can't get past it. Essential for booking, inventory, ticketing and payments.

db/schema.rbbookings
exclusion_constraint
  "user_id WITH =,
   is_overridden WITH =,
   tsrange(starts_at, ends_at) WITH &&",
  using: :gist,
  name: "booking_slot_should_not_overlap"

The rule lives in Postgres, so it holds everywhere.

Performance · NeetoCal

Availability in real time, 40× fewer checks.

"When is this person free?" depends on working hours, overrides, holidays, buffers, booking limits, group seats and busy times from Google, Outlook and iCloud. For team meetings it runs for every member at once.

  • A serious slot engine. About 5,000 lines of Ruby and 560 tests, covering one-on-one, round-robin, collective and group meetings.
  • Binary search in the hot path. Booking times are kept as sorted integers, and costly time zone lookups became integer math.
  • No brute force. "First available date" estimates each day's capacity with one grouped SQL query instead of generating 18 months of slots.
  • Cached and de-duplicated. Results live in Redis, and a unique-job lock stops a traffic spike from starting a thousand identical calculations.

What you getEngineers who profile, find the real bottleneck and fix it with the right algorithm, not a bigger server bill.

Comparisons needed to validate slots, from NeetoCal's slot engine.

Media pipeline · NeetoRecord

380K recordings, ready the moment you stop.

People paste the link the second they press stop. Videos run for hours and arrive from Chrome, Firefox, Safari, extensions and a desktop app, each in a different format.

  • Rails never touches the video bytes. It coordinates a direct S3 multipart upload, so app servers stay light.
  • Crash-proof. If a laptop dies mid-recording, NeetoRecord finishes the video from the parts that reached S3.
  • The right path per browser. Chrome's video is repackaged without re-encoding; Firefox's is encoded once; Safari has its own path.
  • Smart editing. A trim re-encodes only the affected 8-second segments, with one-click revert.
  • Serverless where it fits. AWS Lambda handles transcoding and AI; recordings over 45 minutes move to our own compute cluster.

What you getEngineers who have built media pipelines that are fast for users and careful with cloud costs.

RecordingChunks stream straight to S3Presigned multipart upload, Transfer Acceleration
At 20 sAI writes the titleBefore you press stop, so link previews look right
On stopParts stitched, Lambda runsRemux or encode to a streaming-ready MP4
In parallelTranscript, summary, chaptersPlus thumbnail, GIF preview and hover sprites
Every 2 hSelf-healing sweepRe-runs any upload that was never processed

Integrations · NeetoCal

Integrations that survive the provider's bad days.

A booking touches Google, Outlook or iCloud calendars and a Zoom, Meet, Teams, Daily or Whereby room. Each provider fails differently. If one breaks, hosts get double-booked or guests get an invite with no link.

  • Two-way calendar sync. If a host drags a meeting in Google or Outlook, NeetoCal reschedules the booking.
  • Failure handling, designed up front. Every provider has a written error policy: what retries, what asks the user to reconnect, what is safely skipped.
  • A meeting link, always. If the host's video provider fails, NeetoCal falls back to our self-hosted Jitsi server, then moves meetings back when the host reconnects.
  • Subtle races, caught. Room creation waits until every database transaction has committed, so workers never read half-saved bookings.

What you getEngineers who design the failure path first, so your customers rarely see it.

GooglePush channels, sync tokens, automatic full resync. Renewals spread over 30 minutes to respect API limits.
OutlookMicrosoft Graph subscriptions renewed every 2 hours, delta sync, daily full resync.
iCloudNo push support, so jittered polling every 5 minutes that re-reads only changed calendars.
VideoHost's provider first, self-hosted Jitsi as a guaranteed fallback.
NeetoDeploy

Our engineers built their own Heroku. In Rails.

Running 20+ products on a commercial platform gets expensive, and you lose control over builds, scaling and cost. So our team built NeetoDeploy, a full platform-as-a-service on Kubernetes, with a Rails app as its control plane.

0Service objects in the Rails control plane
0Background job classes
0Test files
0+Buildpacks written in-house
PushGitHub webhookRails picks up the commit
BuildBuildpacksWarm ARM and x86 build nodes
TestNeetoCIKubernetes shards share one Redis test queue
ReleaseKubernetesRelease jobs, then traffic via Traefik
RunScale and watchLatency-based autoscaling, logs, costs

Kubernetes on AWS

Amazon EKS with Karpenter provisioning ARM (Graviton) nodes. Rails drives the cluster through kubeclient and four companion services.

A review app for every PR

Each pull request gets its own app, URL and TLS certificate. New pushes cancel stale builds; closed PRs clean up automatically.

Apps that sleep and wake

Idle apps scale to zero. The next visitor sees a wake screen while the web and database pods come back up.

Autoscaling on real signals

Scale on Sidekiq queue latency, response time or a schedule. A custom controller reports every scaling event back to Rails.

Managed add-ons

Postgres 14 to 18, Redis and Elasticsearch, with scheduled backups, one-click clones, import, export and memory alerts.

Logs, TLS, cost control

Logs in ClickHouse, automatic Let's Encrypt certificates, and daily AWS cost reports per app.

What you getEngineers who know the whole stack, from the Rails model to the Kubernetes node. They can scale your app, cut your hosting bill or move you off Heroku.

How we work

The habits of a world-class team.

157 unique indexes · 212 foreign keys

The database enforces the rules

Constraints and triggers catch what application code misses.

784 migrations, zero-drama deploys

Safe migrations, always

Unsafe changes are blocked before review. Long backfills run in the background, never blocking a deploy.

~8,500 tests · 487 Playwright specs

Tested at every level

Unit and browser tests run in parallel on our own CI. Time zones and race conditions are tested on purpose.

One bug, one test

Every bug fixed once

A production fix ships with a test named after the real failure.

Flipper flags

Staged rollouts

New features ship behind flags, gated in both the API and the UI.

Rails 8.1 · Ruby 4.0

Always current

Upgrades across 20+ apps are routine work, not a yearly project.

Work with us

Work with the engineers who built Neeto.

Scaling a Rails app, adding AI, processing video, taking payments or moving off Heroku: our team has done it in production, for our own products. Now let them do it for yours.

Talk to usSee our Rails services