T-shaped engineer with 10+ years of experience across drug discovery, ERP, education, e-commerce, and entertainment, specializing in end-to-end digital solutions that integrate people, process and technology.
No framework operates alone — each one feeds the next. Domain boundaries inform the diagrams, the diagrams get checked against the Well-Architected pillars, and every decision that survives review gets written down.
Member of DART, Leapfrog's Technical Decision Authority and Architecture Review Board. Own end-to-end solution design and execution strategy across projects, author engineering standards and guardrails, and give binding technical guidance when teams need a ruling.
Led engineering teams through problem analysis, solution design, and infrastructure architecture. Acted as the bridge between project management, clients, and engineering — turning requirements into systems that actually shipped.
Led the engineering team building a SaaS product from early-stage through release — feature architecture, microservice and monolithic development, deployment, and team management.
Collaborated with a distributed team to build a merchandise design product from the ground up through deployment.
Requirement analysis and estimation, feature design and development, build and deployment, and mentoring of junior engineers.
Designing a hybrid-intelligence SDLC where thirteen role-agents cover the full engineering surface — product through SRE — against a six-spec library that acts as the single contract across the pipeline. Humans hold the validation gates; a dual metrics framework keeps system-health (DORA) and partnership-health separately honest, so automation gets measured on trust, not just throughput.
"Every note's feeling comes from its distance to your root. No memorizing the fretboard — just follow the feeling, and let it point the way." An interactive tool that reframes music theory around interval-to-root relationships instead of rote fretboard memorization — the same instinct for finding the underlying model behind a system, applied to music.
A field guide to the one artifact most teams skip between "we understand the requirements" and "we're building it": the technical blueprint. Walks through the must-haves — functional and non-functional requirements, data flow and ER diagrams, C4 and high-level architecture diagrams, API design, PoC/MVP plans, capacity and cost estimation, staffing, and timeline — and makes the case that a single missed item here is the software equivalent of a house built without wall switches: invisible until it isn't, and expensive at scale.
Built and ran the ARB process for a portfolio where most teams have never touched Agentic SDLC and shouldn't have to. Structured lightweight ADRs and C4-based reviews so a five-person greenfield team and a fifteen-year legacy platform can both pass through the same gate without either one being underserved.
A practical walkthrough of the C4 model — context, container, component, code — for explaining complex systems to technical and non-technical audiences alike, using Amazon.com as the worked example.
Read on MediumA reflective piece on career prioritization — and the cost of spreading yourself across every task instead of the few that actually move you forward.
Read on MediumPractical guidance for developers navigating framework churn — jQuery to ES6 to Angular to React — drawn from a panel discussion at a Kathmandu JS meetup.
Read on MediumA personal list of core professional values — patience, documentation, working smart over hard — distilled from early years as a developer.
Read on MediumSmall teams don't need an Enterprise Continuum. I reach for evolutionary architecture — fitness functions and modular boundaries — and let structure emerge as the domain gets clearer, not before.
For the 10-year-old systems, I map bounded contexts first, then carve migration paths with the Strangler Fig pattern. Agentic SDLC earns its keep here, at the cross-project, cross-team scale.
Context, decision, consequences. If it's not an ADR, it's an opinion — and opinions don't survive the next hire, the next reorg, or the next me revisiting the problem in a year.