Backend systems and APIs

What this is

Everything behind the screen: the database, the API that web and mobile talk to, the jobs that run at night, the connections to your ERP, CRM, payment provider or accounting system. When a business says "our systems do not talk to each other", this is the work that fixes it.

What you get

  • A data model written down before code, reviewed with you, so the words in the database match the words your staff use.
  • A typed API with versioning, authentication, rate limits and useful error messages. Documented with examples that actually run.
  • Integrations with the systems you have: REST, SOAP, SFTP drops, webhooks, CSV exports from software older than us. We have seen most of it.
  • Background jobs with retries, dead-letter handling and alerts that reach a human.
  • Migrations that can be rolled back. Backups that have been restored at least once, by us, in front of you.

Typical scope

  • A single API that unifies two or three internal systems behind one consistent interface.
  • Replacing a nightly manual export with an automated, monitored sync.
  • The backend for a new web or mobile product, with authentication, billing and admin.

How we build it

// Every external call is typed, timed, retried and logged. Boring on purpose.
const invoice = await erp.invoices.get(id, {
  timeout: 8_000,
  retries: { attempts: 3, backoff: "exponential" },
  idempotencyKey: `invoice:${id}:${version}`,
});
  • Correctness first. Idempotent writes, explicit transactions, and tests for the ugly paths: duplicates, partial failures, retries.
  • Observability from day one. Structured logs, request ids that cross system boundaries, and a dashboard you can read without us.
  • Least privilege. Every integration gets its own credential with the smallest scope that works, stored in your secrets manager, rotated on a schedule.

Timeline

Two to ten weeks. Pure API work tends to be quick; integrations with legacy systems take as long as the legacy system's documentation is wrong, which we find out in the first week and tell you.

Good fit if

  • You can name the systems involved and get us read access to their documentation and a test environment.
  • There is someone on your side who knows what the data means.

Not a fit if

  • The other system has no API, no export and no owner. We can sometimes still help, but we will say honestly when the right answer is replacing it.

Related