About
A senior engineer for the phase where the system has to hold.
I've spent twenty years writing production software, nine of them inside a Fortune enterprise, and the rest across product teams, consultancies, and founder-led builds. This page is the honest version of that.
Engineering Standard
HA"I build for the moment after launch, when the easy answers are gone and the system has to protect revenue, data, and trust."
Herbert Amburn
Senior engineering practice
Identity
Who is behind the practice
I'm a senior software engineer, systems architect, and long-term technical partner. My work sits at the intersection of three disciplines that most teams keep separate: full stack product engineering, Salesforce & CRM architecture, and AI workflow automation.
I don't chase frameworks. I've been through enough migrations - from SOAP to REST, from monoliths to event-driven, from LAMP to serverless, from rule engines to LLMs - to know that architecture decisions are expensive, and that the cost is paid by the team maintaining the system two years after the launch email.
Most of my engagements are with founders, CTOs, and heads of operations who have inherited or grown a system that now has to behave under real load, real audits, real customers. My job is to make it hold - and to leave it in a shape their next engineer can extend without a rewrite.
What I actually believe
Systems, not features
A shipped feature is a promise. A shipped system is an asset. I build for the second one - even when the brief only asks for the first.
Ownership from day one
Code that no one owns rots. I take ownership of what I ship - CI, observability, on-call knowledge, hand-off - and I write for the engineer who inherits it.
Boring where it matters
Novelty in the wrong layer is a bug. I pick boring database engines, boring queues, and boring auth flows so that the interesting work can happen where it actually creates value.
Business context is a technical input
Requirements are never complete. Understanding the business - margins, contracts, seasonality, regulator, salespeople - is part of the engineering job, not an afterthought.
Standards
How I work
Written first, spoken second.
Design docs, ADRs, runbooks. If it can't be written down, it's not a decision - it's a hope.
Small releases, frequent releases.
Continuous delivery with rollback. Big-bang releases are a form of ceremony, not engineering.
Observability is not optional.
Every service ships with logs, metrics, and traces. If we can't see it, we can't own it.
One environment of record.
No 'it works on staging.' Production parity in dev, seeded data, deterministic tests, honest CI.
The handover is the deliverable.
The engagement ends when your team can operate, extend, and reason about the system on their own.
Next step