S Stack

Every technology here, and the system it shipped in.

A stack list with no context is a keyword dump — it tells you what someone has installed, not what they've operated. So each entry below carries the production system it ran in and an honest depth marker.

Production owned or built it in a live system
Working used it in delivery, not my primary surface

01 Cloud

Cloud & infrastructure

The surface I'd most want to be hired for. Two clouds operated in parallel through a live migration, one bill cut by ~88%, and a microservices fleet on managed Kubernetes.

AWS

  • EKSProduction
  • ECS on FargateProduction
  • Elastic BeanstalkProduction
  • CognitoProduction
  • LambdaWorking
  • EC2 / PM2Working

Leafgistics WMS · Sehat Kahani migration · telehealth backend.

Azure

  • App ServicesProduction
  • FunctionsProduction
  • Application GatewayProduction
  • Azure MySQLProduction
  • Blob StorageProduction

The ~88% cost redesign, and the platform still running while AWS came online beside it.

Platform

  • KubernetesProduction
  • DockerProduction
  • GitHub ActionsProduction
  • GitLab CIProduction
  • Load balancingProduction

CI/CD gating a multi-service fleet, and five environments across three product lines.

02 Backend

Backend & APIs

Node and TypeScript are home. Python is where the AI tooling lives. Both have carried real traffic in healthcare and logistics.

Languages

  • TypeScriptProduction
  • JavaScript / NodeProduction
  • PythonProduction

Warehouse services, consultation backends, MCP servers.

Frameworks

  • ExpressProduction
  • Koa2Production
  • AngularWorking
  • ReactWorking

Including the Angular operations console used to run a national telemedicine platform.

Real-time & messaging

  • NATS StreamingProduction
  • WebRTC (OpenTok)Production
  • Server-Sent EventsProduction
  • Socket.ioProduction
  • PubNubProduction
  • Twilio VideoWorking

An event bus behind a WMS, and video consultations that patients actually joined.

03 AI

AI / LLM tooling

Treated as systems work, not prompt work. The interesting decisions are the tool boundary, the memory split, and where the safety gate sits.

Protocols & orchestration

  • Model Context ProtocolProduction
  • LangGraphProduction
  • LangChainProduction
  • ChainlitProduction

One MCP server built solo, one open-source MCP server contributed to.

Memory & state

  • PineconeProduction
  • CassandraProduction
  • Vector retrievalProduction

Semantic memory and durable account facts kept deliberately separate.

Providers

  • Anthropic ClaudeProduction
  • OpenAIProduction
  • Google GeminiProduction
  • Fine-tuningWorking

Multi-provider by design — different graph nodes want different trade-offs.

04 Data & mobile

Storage, and the client side

Transactional and analytical storage, plus the mobile delivery side that 70+ published applications ran through.

Databases

  • MySQLProduction
  • PostgreSQLProduction
  • MongoDBProduction
  • RedisProduction

Schema design, caching and multi-tenant schema evolution under live load.

Analytical

  • ClickHouseProduction
  • Amazon RedshiftProduction
  • OLAP modellingProduction

Migrated warehouse search off Redshift onto ClickHouse across three sites.

Mobile

  • React NativeProduction
  • Expo / EASProduction
  • CallKit / TelecomWorking
  • Native modulesWorking
  • FlutterWorking

Release pipelines with version-consistency gating, offline-first sync, native call integration.

05 Opinions

What I'd reach for, and why

  • Managed compute over self-managed nodes on a small team. Fargate exists so four engineers can spend their week on domain logic rather than node health.
  • An event bus when one real-world action has several consequences — not because microservices are fashionable. If the audit trail is a consumer rather than a logging afterthought, you get a defensible record for free.
  • Consumption billing for anything trigger-driven. The cheapest compute is the compute that isn't running; most cloud bills are paying for idle.
  • Narrow tools over one wide one when exposing anything to an LLM. A single run_sql escape hatch is easy to build and impossible to reason about.
  • Separate semantic memory from durable facts. Conflating them is how agent systems start contradicting their own database.
  • Incremental cutover over rewrites. Every migration I've run stayed live throughout, because there was never an acceptable window to be down.

Next

See where any of this actually ran.

Four case studies go into the architecture, the trade-offs and what I'd change.