Experience
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
Field Notes
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.
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.
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.
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.
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.
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.
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.
Why Adaptation Was Natural
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