This is where most of my time goes. Python (Django, DRF, FastAPI) for product services and APIs, Ruby on Rails when the domain already lives there, and Node with TypeScript for integration services. What changes between projects is rarely the framework: it is the data model and where the boundaries between services are drawn.

Not my main job, but I have built and maintained a fair amount of operational UI: KYC review panels, A/B experiment dashboards, real-time delivery tracking. React and Next.js are my usual ground, and Angular shows up when the team is already there. On screens like these, making the state legible matters more than anything else.

PostgreSQL by default, and the rest when there is an actual reason: Redis for queues and cache, ClickHouse for multitenant analytics, pgvector and Pinecone when semantic search over your own data is needed. Pipelines (Airflow, ETL, Segment) are usually half the real work, even though they never show up in the UI.

This shows up when two services can no longer wait for each other. Kafka and RabbitMQ for events, Temporal for flows that run for days and have to survive a restart, gRPC and Protobuf when the contract matters more than convenience. The patterns here (outbox, saga, idempotency) exist because in production events arrive duplicated, late or out of order.

AWS and GCP on Kubernetes, with Terraform or Pulumi depending on what the team already uses. My goal is for deploying to be boring: a reproducible pipeline, a one-command rollback and enough instrumentation to answer what broke without opening a debate. I don't treat observability as an extra at the end of the project.

Agents and retrieval inside the product, not as a demo. At StyleSeat they were agents that take repetitive work off professionals; at Mastercard, fraud detection models connected through MCP; on other projects, RAG over first-party data. What decides whether it works is almost never the model: it is the data reaching it and the evals that measure it.