Platform & Backend Engineer, Ahmedabad, India
Right now, that’s the internal developer platform at Techolution: built in four months, used by 150+ engineers, and the reason a deployment takes 15 minutes instead of days.
What I do
Most of my best work sits in the gap between two systems. A few of them:
GitHub connected to Cloud Build
Cloud Build caps triggers at 600, and our CI was trigger-based. I replaced it with a GitHub App → Pub/Sub → expander pipeline: ordered per-deployment queues and a 45-retry dead-letter queue.
No trigger ceiling; durable, auditable delivery.
Vertex AI connected to Post-processing engine
Our post-processing engine expected complete LLM responses. I streamed Vertex AI tokens through it in chunks instead of waiting for the full generation.
5× faster first response on a production RAG chatbot.
Slack & Teams connected to Jira & ServiceNow
A multi-tenant, event-driven service linking Slack and Teams to Jira and ServiceNow, with severity classification and escalation workflows, built on FastAPI, PostgreSQL and Pub/Sub.
Load-tested at 5,000+ events per hour.
Smart-home app connected to LLM agent
I intercepted the vendor app’s traffic with a MITM proxy and packet captures, found its MQTT control channel and decoded the payloads, then put a LangChain + Gemini agent on top.
Voice control through iPhone Shortcuts, self-hosted 24/7.
Cloud Tasks connected to Trial Releases
Trial releases run for a set window, from 30 minutes to 6 hours. Cloud Tasks schedules an automatic revert to the last known-good build unless a newer build succeeds.
Part of the approval and release state machine I own.
Kubernetes client connected to Bulk deletion
The Python Kubernetes client failed during bulk service deletion. I root-caused the defect, added safeguards, and routed the affected calls through kubectl.
Bulk deletions made safe again.
Experience
Tools: Python · FastAPI · GKE · Cloud Run · Argo CD · Helm · Pub/Sub · Cloud Tasks · MongoDB · PostgreSQL · Vertex AI
Tools: Python · Flask · AWS Textract
Tools: SQL · Python
Manipal University Jaipur · B.Tech, Information Technology · CGPA 8.17/10
Skills
Case study · Internal developer platform
Shipping a new service used to take 2–3 days. I co-architected an internal developer platform, built from scratch in four months, that turned it into one self-service workflow: from a repository to a running, health-checked service on GKE or Cloud Run, whether it’s a frontend, a backend or an AI agent. Behind that workflow is a whole platform: CI, GitOps delivery, autoscaling and routing, access control and approvals, self-reverting trial releases and an audit trail of every change.
Self-service
Platform
Three FastAPI services, split from a monolith so each uses the scaling method that fits its load.
Built on
Orchestration
A FastAPI engine runs each deploy as a series of stages, 9 on GKE and 5 on Cloud Run, including the CI build, pod sizing from measured usage plus 25% headroom, health checks and the Argo CD handoff. When a stage fails, its retry cleans up partial resources first.
CI
Cloud Build caps triggers at 600, and CI used to be trigger-based. Now a GitHub App publishes every push to Pub/Sub, and an expander routes it into ordered per-deployment queues, with a 45-retry dead-letter queue and approval gates driven by PR summaries.
Delivery
The platform generates each service’s Helm chart and versions it in GitHub. Argo CD syncs it to GKE and waits for pods to be ready, and Kyverno admission policies block out-of-band changes, so configuration doesn’t drift from Git.
Scaling & routing
Teams pick CPU-based autoscaling with HPA or request-based with KEDA. Each environment routes through NGINX, GCE Ingress or the Kubernetes Gateway API, and the pipeline adapts the routing to match, so nobody needs direct Helm access.
Approvals & releases
Access is ACL-based RBAC backed by MongoDB, and prod and client deployments wait on approval chains of up to three levels. Trial releases run for 30 minutes to 6 hours, then Cloud Tasks reverts them to the last known-good build unless a newer build succeeds.
Audit
Route-level middleware logs every lifecycle event (deploys, retries, access changes, config, CI pushes, promotions) with its full request and response. That log powers per-user history, AI-generated change summaries and one-action revert to any earlier stable version.
I own the orchestration engine, the approval and release state machine and the event-driven CI pipeline. I also implemented the GitOps delivery, shipped the autoscaling and routing options, built the audit log, and co-designed the split into three services.
Tech blog
Deep dives on the problems above, written for engineers who hit the same walls. The first posts are in progress.
Why trigger-based CI hits a wall, and the GitHub App → Pub/Sub → expander design that replaced it.
Streaming LLM output through a post-processor: 40s to 8s
Reverse-engineering my smart home’s MQTT protocol