Service

Backend + APIs

We build the systems behind the UI. REST APIs, GraphQL, WebSocket / SSE, background-job processing, integrations with third-party services. Our SaaS line runs ~50 production endpoints in Rails (Outsourcing, Finance) and Node/TypeScript (HRS, Logistics, Leads, CMS) — same stack we recommend.

Concrete deliverables

  • REST + GraphQL APIs — versioned, documented (OpenAPI), authenticated (OAuth2, JWT, API key).
  • Background-job pipelines — Sidekiq, BullMQ, Celery; cron + scheduled jobs.
  • Real-time features — WebSocket, Server-Sent Events, pub/sub via Redis or Kafka.
  • Third-party integrations — Stripe, SendGrid, Twilio, DocuSign, Salesforce, HubSpot, Airtable.
  • Webhook handling + retry — idempotency keys, dead-letter queues, replay tooling.
  • Migrations — language migrations (Rails → Go, PHP → Node), framework upgrades (Rails 5→7, Node LTS), database migrations (MySQL → Postgres).

What we work with

We pick what fits your team. We don't push our preferences when your stack works.

Languages

Node.js + TypeScript (deepest) · Ruby on Rails · Python (FastAPI, Django) · Go · Java/Kotlin (Spring) · Elixir/Phoenix (specialised)

Databases

PostgreSQL (default) · MySQL · MongoDB · Redis · DynamoDB · ClickHouse

Queues + jobs

Sidekiq (Ruby) · BullMQ (Node) · Celery (Python) · RabbitMQ · Kafka · AWS SQS

API patterns

REST (default) · GraphQL · tRPC · gRPC (internal RPC) · WebSocket · SSE

ORMs

Prisma (TypeScript) · ActiveRecord (Rails) · SQLAlchemy (Python) · Drizzle (TypeScript)

Testing

Vitest, Jest (Node) · RSpec, Minitest (Ruby) · pytest (Python) · Postman/Bruno + automation

How we work

01

Discovery (1 week)

API contract design, data model, third-party integration mapping. Output: OpenAPI spec + ERD diagram.

02

Schema + scaffolding (1 week)

Database migrations, model layer, seed data, base auth. Nothing exposed to the world yet — but the foundation is testable.

03

Build endpoints (3-8 weeks)

Route by route, with tests. Sequence by dependency: read-only first, writes second, integrations third.

04

Production hardening

Rate limiting, observability, log aggregation, on-call runbooks. Postman/Bruno integration test suite for ongoing health checks.

From our own production

Merot Outsourcing API (Rails 7)

70+ controllers, JWT auth, Sidekiq for background jobs, Stripe + DocuSign + SendGrid integrations. Multi-product (admin / employer / employee) with role-based access.

Merot Logistics backend (Node + TS + Prisma)

Multi-tenant white-label SaaS — shipments, COD, GPS, BullMQ for background sync, Infobip SMS/WhatsApp integration.

Merot CMS (Node + TS + Prisma)

Headless content API serving merot.com + outsourcing blogs. Public read endpoints + admin write.

Engagement model

Backend project: $30-200K depending on scope (single endpoint integration vs. full SaaS backend). Embedded backend engineer: monthly retainer. We're language-flexible — we'll work in your existing stack rather than push our preferences.

Frequently asked questions — Backend + APIs

Rails vs. Node vs. Go — what do you recommend?

Default: Node + TypeScript for new projects under a 5-person team. Rails when you want maximum convention + speed-of-build for CRUD apps. Go when latency matters + your team already runs Go. We don't push a stack — we pick what fits your team.

Do you write tests?

Yes — the kind you can actually maintain. Unit tests for pure logic, integration tests for the API surface, end-to-end tests sparingly. Coverage isn't a goal; correctness is.

Database — Postgres or something else?

Postgres is the default. MySQL when you've inherited it. Mongo for genuinely document-shaped data (rare). DynamoDB / Cassandra when you've outgrown Postgres scale (very rare for most clients).

Idempotency for webhooks?

Yes — every webhook handler we write is idempotent. We assume the sender will retry (because they will). Dead-letter queue for failures, replay tool to reprocess.

Background jobs — what stack?

Sidekiq for Rails. BullMQ for Node. Celery for Python. We don't recommend reinventing — these are mature.

GraphQL or REST?

REST by default — simpler to debug, cache, and rate-limit. GraphQL when the client team specifically needs it (deeply nested reads with strict typing). We won't push GraphQL just to have it.

How do you handle long-running operations?

Background job with status polling endpoint, or webhook callback when complete. We avoid keeping HTTP requests open longer than 30 seconds.

What about gRPC?

Used internally between services where latency matters (e.g. our PDF service does gRPC under high load). Rarely exposed externally — REST is friendlier for clients.

Let's scope your backend + apis project

Free 60-min discovery call. 6-page written brief in 48 hours.