Twenty years of production software - six defined eras.

A detailed account of the projects I undertook, the issues I found in production, and the engineering judgment that let me keep adapting as software moved from pages to APIs, platforms, cloud, and AI.

Production Judgment

HA
"Experience is not the number of projects finished. It is the number of hard problems solved without losing the system."

Herbert Amburn

Twenty years in production software

The work that changed my judgment was not the happy-path launch; it was tracing a bad deploy through stale cache, retry queues, record-lock contention, permission-set drift, unmasked PII in logs, and the one integration job that only fails when month-end volume hits.

I build with rollback, idempotency, data lineage, and auditability in mind because those are the handles you reach for when the dashboard is green but the business is not.

  1. Era / 01

    2005 - 2009

    LAMP stack, jQuery, hand-rolled auth.

    Stack / PHP / MySQL / JavaScript / Linux / Apache

    Web engineer / early SaaS

    Projects Undertaken

    Built CMS-backed marketing sites, custom shopping carts, reporting screens, and internal admin tools when most business software was still server-rendered. The work was close to the metal: PHP templates, MySQL schemas, Apache configuration, session handling, file uploads, payment form flows, and browser behavior that changed by vendor and version.

    Issues Identified

    The problems were rarely glamorous. Shopping carts lost state when sessions expired. Admin users double-submitted forms. Slow pages came from N+1 queries and missing indexes, not from the language itself. I learned to read server logs, inspect SQL plans, reproduce browser-specific failures, and think through what happens between a click, a request, a database write, and a response.

    Insight And Skill Gained

    That period gave me a durable respect for fundamentals: HTTP, relational modeling, authentication, input validation, caching, backups, and the difference between code that works once and code that survives real users.

    Adaptation To Next-Gen Software

    Because I understood the request lifecycle and data layer directly, moving into richer front ends and API-driven systems did not feel like reinvention. It was the same transaction model, split across more moving parts.

  2. Era / 02

    2009 - 2013

    SPA emergence, REST becoming default.

    Stack / Node.js / Backbone / Angular / MongoDB / Postgres

    Full stack engineer / agency and product

    Projects Undertaken

    Moved legacy jQuery-heavy interfaces into structured front-end applications, built JSON APIs, designed customer portals, reporting dashboards, workflow screens, and multi-role CRUD systems for teams that needed faster interaction than server-rendered pages could provide.

    Issues Identified

    The hard lessons came from contract drift. A field renamed on the server broke the client. A nullable value became a runtime edge case. The UI could show optimistic state that the database rejected seconds later. I had to learn versioned endpoints, validation on both sides of the wire, predictable error payloads, and client state that did not lie to the user.

    Insight And Skill Gained

    I became a true full-stack engineer here: schema, endpoint, auth, client state, UI behavior, deployment, and support. I learned that an interface is only as good as the contract behind it.

    Adaptation To Next-Gen Software

    That made the move into typed APIs, component architectures, and modern front-end frameworks natural. React, TypeScript, and GraphQL were new tools, but the underlying discipline was already there: explicit contracts and controlled state.

  3. Era / 03

    2013 - 2017

    Monolith-to-service transition inside a regulated business.

    Stack / C# / .NET / SQL Server / WCF / MSMQ

    Senior engineer / enterprise .NET

    Projects Undertaken

    Owned business domains inside larger .NET systems: billing workflows, inventory-style operational data, integration services, reporting extracts, role-based admin tools, and back-office processes where a bad deploy affected real money and real customers.

    Issues Identified

    The issues were production-grade: invoice totals that had to reconcile, jobs that had to resume after partial failure, SQL locks that appeared only under batch volume, service calls that timed out but still committed downstream, and reports where one wrong join could change the story executives saw on Monday morning.

    Insight And Skill Gained

    I learned defensive engineering: transactions, idempotency, audit tables, retry behavior, reconciliation reports, release notes, rollback planning, and the habit of asking how a system fails before asking how it launches.

    Adaptation To Next-Gen Software

    Those habits transferred directly into cloud and distributed systems. Once you have handled partial failure inside an enterprise monolith, queues, workers, serverless functions, and event-driven services make sense as sharper tools for the same reliability problem.

  4. Era / 04

    2017 - 2020

    Sales Cloud, Service Cloud, CPQ-style workflows, and integrations.

    Stack / Apex / LWC / Flow / Platform Events / SFDX

    Salesforce architect / Fortune enterprise

    Projects Undertaken

    Worked deep in Salesforce across Sales Cloud, Service Cloud, CPQ-style processes, Lightning interfaces, Apex services, Flow automation, integrations, data migrations, and operational workflows used by sales, service, finance, and compliance-facing teams.

    Issues Identified

    I inherited the kind of org that experienced Salesforce people recognize immediately: overlapping triggers, bypass flags, workflow rules nobody wanted to delete, Process Builder logic that fired in surprising order, profiles doing the work permission sets should have done, and integrations that treated Salesforce like a simple database instead of a governed platform.

    Insight And Skill Gained

    I learned platform architecture: trigger frameworks, service layers, governor-limit thinking, bulk-safe Apex, Flow ownership, deployment discipline, sandbox strategy, permission modeling, and how to translate messy business rules into automation admins could maintain without breaking production.

    Adaptation To Next-Gen Software

    That made AI and automation easier to adopt later because Salesforce taught me where business logic really lives. New tools only matter when they fit the operating model, permissions, audit trail, and human approval path of the business.

  5. Era / 05

    2020 - 2023

    Serverless-first, event-driven, observable by default.

    Stack / TypeScript / Node.js / AWS Lambda / Azure Functions / Kafka / Postgres

    Principal engineer / cloud and event-driven systems

    Projects Undertaken

    Led cloud-native builds and migrations: API gateways, serverless workers, event pipelines, data sync services, background processing, customer-facing dashboards, and integration layers connecting SaaS tools, CRMs, databases, and legacy systems.

    Issues Identified

    Distributed systems made old failure modes louder. Messages arrived twice. Webhooks came out of order. A retry could create duplicate side effects. Logs existed but did not answer the question. Deployments succeeded technically while one downstream contract quietly changed. I learned to treat observability, dead-letter queues, schema validation, and rollback as core product features.

    Insight And Skill Gained

    This period sharpened my judgment around boundaries: typed payloads, idempotency keys, correlation IDs, structured logs, traceable events, infrastructure as code, CI/CD gates, and operations dashboards that let a team debug from evidence instead of suspicion.

    Adaptation To Next-Gen Software

    Those patterns are the backbone of next-generation software. Cloud services, AI workers, and automation systems all need the same discipline: clear inputs, safe execution, visible state, and a way to recover when reality disagrees with the happy path.

  6. Era / 06

    2023 - Present

    LLMs integrated into real operational systems, not demos.

    Stack / Python / LangGraph / pgvector / OpenAI / Claude / Next.js

    AI workflow architect / practice lead

    Projects Undertaken

    Built AI workflow systems around real operational work: RAG over enterprise documents, structured extraction from forms and contracts, CRM copilots, AI-assisted routing, internal knowledge assistants, chatbot and voice-assistant flows, and tool-using agents connected to business APIs.

    Issues Identified

    The core issue was never whether the model could produce an impressive answer. It was whether the answer was grounded, permission-aware, auditable, recoverable, and safe to place inside a business process. Hallucinations, stale source material, prompt injection, missing citations, vague evals, and unreviewed tool calls all had to be designed against.

    Insight And Skill Gained

    I learned to treat AI as a system component, not a magic layer: retrieval quality, chunking strategy, eval sets, prompt versioning, typed tool calls, human review queues, confidence thresholds, source citations, and logs that explain why the system did what it did.

    Adaptation To Next-Gen Software

    This is where the earlier eras compound. Web fundamentals, API contracts, enterprise controls, Salesforce workflows, cloud events, and observability all feed into production AI. That is why adapting to next-generation software felt seamless: the new interface changed, but the engineering principles underneath did not.

New software keeps changing. The failure modes rhyme.

Every major shift in my career prepared me for the next one. Server-rendered web apps taught the request lifecycle. APIs taught contracts. Enterprise systems taught auditability and release discipline. Salesforce taught how business logic actually moves through a company. Cloud taught partial failure, observability, and recovery. AI now sits on top of all of that.

That is why next-generation software has not felt like a hard reset. Whether the tool is a JavaScript framework, a serverless event pipeline, a CRM automation, or an LLM-powered workflow, the senior work is the same: model the business correctly, define clean boundaries, protect the data, make the system observable, and design for the day something breaks.

20+

Years in production

9

Years enterprise Salesforce

100+

Services taken to prod and kept there