About
I've spent 13 years building backend systems and data infrastructure. Started with web development in 2010, moved through LAMP, Node, and cloud infrastructure at scale. Most of my career — five years — was at ConvertCart, where I owned a data platform end to end: from ingestion and modelling through serving to reporting. Led a team through a complete rebuild. Built segmentation and recommendation engines on top. Shipped architectures handling 100+ customer stores across five e-commerce platforms (Shopify, BigCommerce, WooCommerce, Magento).
I'm now looking for my next high-ownership role — Staff Engineer, Founding Engineer, or Backend Architect at a Series A–B startup, remote or Bengaluru-based. Interested in systems that are live in production, carrying real user value, with real constraints.
What I get hired for
Platform ownership
End-to-end responsibility for systems serving multiple internal teams and hundreds of external users. Comfortable holding both the design decisions and the operational debt. "Who owns this when production breaks?" — that person.
Refusing reversible complexity
Ship simpler systems by deferring normalization to layers where mistakes are cheap to fix. Trade off one-time complexity at ingest for ongoing flexibility. Spend operations cost to buy reversibility.
Scaling with small teams
Built systems serving 100+ customers with 6 engineers. Focus on automation, clear ownership, and choosing the right abstractions so humans don't become the bottleneck.
Judging tradeoffs honestly
Every architecture decision trades something off. Value candidates and team members who name the cost admitted, not just the benefit gained. Leads to better hiring and fewer bad surprises post-launch.
Engineering Principles
Reversibility
Normalise where mistakes are reversible; defer normalisation where they're not. A wrong materialized view is a redefinition away from correction. A wrong schema at ingest is a multi-service migration. Applied at the data platform: land raw, fan-out shaped. Applied at segmentation: consolidate first, model at the analytics layer second.
Match storage to question
Recommendations want point lookups; segmentation wants population filtering; reporting wants columnar aggregation. One database cannot efficiently answer all three. Choose the storage pattern for the access pattern, not the other way around.
Operational simplicity beats sophisticated abstractions
Legible systems are easier to debug than clever ones. A Pub/Sub consumer publishing lag metrics and failing visibly beats a Dataflow job hiding what's actually happening in an execution graph. When a small team owns it, debuggability under pressure beats a better abstraction on paper.
Ship in trust order, not sophistication order
Built manual recommendation blocks first (zero intelligence, but deployable day one), then automated, then smart. Clients who started on manual graduated to smart. Sophistication matters less than adoption; adoption requires trust.
Let's talk about infrastructure, data, and building at scale.
mail4udhaya@gmail.com