Skip to content

Practice

Backend and platform engineering

APIs, multi-tenant backends, integrations and background jobs that hold up in production, led by an engineer who has owned these subsystems in live products.

Discuss your project

Problems we solve

  • A guarantee such as "nobody gets double-booked" that your tests never actually exercise.
  • Money computed in several places, so the same amount differs from one screen to the next.
  • EHR vendors that each send data in different formats, so every new hospital threatens a rewrite.
  • Customer data that could leak between tenants because scoping is a convention instead of a rule.
  • Coordination that staff still do by hand, with no reliable trigger for the right message at the right time.
  • AI features that need guardrails, fallbacks and a per-customer rollout before they are safe to ship.

Capabilities

Backend and platform engineering

APIs, multi-tenant SaaS backends, integrations and background-job systems that hold up in production.

Led by Muhammad Tahir Hassan KhanBackend Software Engineer

Backend & platform

Backend development

APIs for web and mobile apps with Node.js or Python/FastAPI, on PostgreSQL, MongoDB and Redis.

  • Node.js
  • FastAPI
  • PostgreSQL
  • MongoDB
  • Redis
How it flows4 steps
  1. Web and mobile apps
  2. APINode.js · FastAPI
  3. DataPostgreSQL · MongoDB
  4. Cache and queuesRedis

How we work on this

  1. 01

    First conversation

    Thirty minutes with the practice lead to understand the problem, the system it lives in and who depends on it.

    You get: A clear answer on whether we are a fit.

  2. 02

    Scoping

    The lead who will build the work writes down what will be built, how, and what could go wrong.

    You get: A written scope with approach, risks and price.

  3. 03

    Build in the open

    Weekly demos, written decisions and a shared board, so you always know what changed and why.

    You get: Working software every week, with a decision log.

  4. 04

    Ship and prove

    Tests run on the real database engine, the rollout is staged, and the handover is written down.

    You get: A staged release and a documented handover.

  5. 05

    Run and improve

    Optional retained support once the system is live, with agreed response times.

    You get: A support agreement, if you want one.

How we work in full

Proof

Healthcare SaaS

Building a Multi-Tenant Care-Coordination Platform for Hospitals

Problem

Coordinating each surgical patient's journey was largely manual, and every hospital ran a different EHR.

What changed

An automation engine for the patient journey, one FHIR-based integration layer for every EHR vendor, and tenant scoping enforced at the data layer.

Result

Patient coordination became automated across hospitals, and a class of timezone and data-mismatch errors that contacted patients at the wrong time was eliminated.

Delivered by Tahir as a backend engineer at a healthcare technology company, before Carpediemsoft.

  • Node.js
  • Express
  • MongoDB / Mongoose
  • Redis
Read the case study
EdTech / SaaS

Hardening a Self-Service Booking Engine

Problem

The booking engine had 36 passing tests, but none of them executed its core guarantee: a tutor can't be double-booked.

What changed

Row locks shared by the booking, confirm and reschedule paths, conflicts checked against both calendars, and every failed slot reported at once.

Result

The locks went from zero executed tests to a suite that proves them on PostgreSQL, including races across plans.

Delivered by Tahir as a full-stack engineer on a multi-country online tutoring platform, before Carpediemsoft.

  • Python
  • FastAPI
  • SQLModel / SQLAlchemy
  • Alembic
Read the case study
EdTech / SaaS

Centralising Tutor Pay and Finance

Problem

Tutor pay was computed three different ways, and the browser did its own maths.

What changed

One server-side rate seam and one earnings aggregate, read by both the earnings card and payout generation.

0 of 29production plans differed after the pay backfill

Result

Three divergent pay computations became one, and the backfill was verified against production before the old columns were retired.

Delivered by Tahir as a full-stack engineer on a multi-country online tutoring platform, before Carpediemsoft.

  • Python
  • FastAPI
  • SQLModel
  • Alembic
Read the case study
All work

Led by

Muhammad Tahir Hassan Khan

Backend Software Engineer · Leads backend engineering

Responsible for

Designs and owns backend architecture, integrations and background-job systems for SaaS products.

Experience

  • Owned core subsystems of a multi-tenant care-coordination platform used by hospital systems: the EHR integration layer, patient-journey automation and tenant-scoped job infrastructure.
  • Backend work on Sokkat, a UAE e-commerce app, and full-stack work on a multi-country online tutoring platform.

Technologies

Backend
Node.js, Express, Python, FastAPI, SQLModel / SQLAlchemy, Bull / BullMQ
Databases
PostgreSQL, MongoDB / Mongoose, Redis, Alembic migrations
Auth & Multi-Tenancy
Auth0, JWT validation, Tenant-scoped data access, HMAC-signed tokens
Healthcare Interoperability
FHIR, HL7, EHR vendor APIs, Clinical event normalization
Integrations
Twilio SMS & Voice, Voice AI agents, Shopify, SMTP & push
AI / LLM
RAG chatbots, LLM triage, Clinical note generation
Frontend & Mobile
TypeScript, Next.js, React, SWR, Flutter
Testing
pytest, Mocha / Chai / Sinon, Vitest, Playwright, Testcontainers
Delivery
CI-gated deploys, Expand/contract migrations, Sentry

Questions

Questions about this practice.

Can you fix or take over a backend we already have?

Yes. We start with an audit, then make root-cause fixes, add tests that prove the concurrency and money logic, and use expand/contract migrations so changes ship safely.

How do you keep one customer's data away from another's?

Every query, background job and cache key is scoped to the right tenant. The tenant is checked, not trusted from the caller, so data does not leak between customers.

Do you integrate with hospital and EHR systems?

Yes. FHIR/HL7 and EHR vendor APIs are normalized into one internal model, with an adapter per vendor, so a new hospital or vendor does not mean rewriting your product.

Can you add AI features to our product?

Yes: RAG chatbots, LLM triage and document generation. They go in with guardrails, a fallback for when the model is unavailable, safeguards for opted-out users and a per-customer rollout.

Have a backend problem like these? Tell us about it.

Discuss your projectSee our work