Umang Raval

Component systems that survive three years of feature requests. Rendering strategy chosen per route, not per framework fashion. Accessibility and performance treated as acceptance criteria rather than a follow-up ticket.

• Design systems in React and TypeScript, documented and versioned
• SSR, ISR and streaming picked per route against real traffic shapes
• Core Web Vitals budgeted in CI, so a regression fails the build
• Tested with real screen readers, not just an automated audit
• Three.js and WebGL for the moments that deserve it, like this page

98median Lighthouse performance

Services designed around the data model instead of the org chart. Explicit contracts, idempotent writes, and back-pressure everywhere something can queue. The interesting part of a backend is what it does at 3am under load, not at noon on a laptop.

• Typed API contracts with clients generated from the schema
• Idempotent consumers and outbox patterns for exactly-once effects
• Zero-downtime schema migrations on live, high-write tables
• Caching, rate limiting and back-pressure designed in from the start
• Contract and load tests wired into every pull request

42 msp99 read latency

Every commit produces one immutable, signed artifact that walks unchanged from staging to production. Rollout is progressive and automated; rollback is a button, not a war room.

• Multi-stage container builds with layer caching and SBOMs
• GitHub Actions pipelines: test, build, scan, push to ECR, deploy to ECS
• Preview environments for every pull request, torn down on merge
• Release notes, changelogs and versioning generated, not typed

< 9 mincommit to production

Infrastructure described in code, reviewed like code, and applied by the pipeline. Observability wired in from the start so incidents are read from dashboards instead of guessed at from vibes.

• Terraform modules with drift detection and plan review in PRs
• CloudWatch dashboards, logs and alarms for every service, in one place
• Error budgets and burn-rate alerts instead of static thresholds
• Lambda automations for remediation, snapshots and scheduled jobs
• Blameless post-mortems that turn into automation, not policy

94%of infra changes fully automated

Landing zones, VPC topology, DNS and ingress laid out once, deliberately, and documented. Multi-account boundaries so a mistake in one workload cannot become an outage in another.

• Multi-account landing zones with isolated blast radius per workload
• TLS at the load balancer, private DNS in Route 53, NAT for egress
• Stateful data on Aurora and S3, with backups and rehearsed restores
• Bare-metal and hybrid: racking, patching, out-of-band management
• Runbooks and diagrams kept next to the code that builds it

3availability zones behind every service

Identity-first access, short-lived credentials, and a supply chain you can actually attest to. Security controls live in the pipeline where they block bad changes, rather than in a document nobody opens.

• Secrets in Vault and KMS with automated rotation and audit trails
• SAST, DAST and dependency scanning enforced as merge gates
• Image signing with admission-time verification in the cluster
• Network policy, mTLS and WAF rules treated as code
• Threat modelling and incident drills before the audit asks for them

0long-lived production keys

Capacity modelled before it is needed, caching layered where the data actually repeats, and failure rehearsed on purpose. Scaling is mostly the discipline of deleting bottlenecks in the right order.

• Horizontal and event-driven autoscaling with KEDA and Karpenter
• Read replicas, sharding and partitioning strategies for Postgres
• Load and soak testing with k6, wired into the release pipeline
• Multi-region failover that has actually been exercised
• Cost as a metric on the same dashboards as latency

12xpeak traffic absorbed, flat latency