Isaac Sornborger, Lead Architect, Serving Infrastructure at Product.ai
Lead Architect, Serving Infrastructure

Isaac Sornborger

Lead Architect, Serving Infrastructure · Product.ai

An aerospace systems engineer who became Product.ai’s serving-layer architect — the engineer who decides what 535,000 SimplyCodes pages do every night, at sub-200ms global delivery.

Twelve years from aircraft-performance pipelines to AI-commerce infrastructure. Builds the substrate the work runs on, not the work itself. Ships the framework, not the feature — and the 535,000 pages are the receipt.

LinkedIn →
Tenure
Founding era · 12-yr engineer
Owns
Serving layer · edge · backend-for-frontend
Surface
SimplyCodes — the cash engine’s substrate
Prior
Northrop Grumman · Santa Clara (BS + MS)
535K
SimplyCodes merchant pages on the stack he architected
<200ms
P95 time-to-first-byte target for global serving
99.9%
Uptime floor he holds every 7-day window
12+ yrs
In infrastructure — aerospace to AI commerce
About

Aerospace systems engineer turned AI-commerce infrastructure architect — the engineer who decides what 535,000 pages do every night.

535K
pages on the serving stack
<200ms
P95 time-to-first-byte
99.9%
uptime floor (7-day window)
12+ yr
aerospace → AI commerce
The range

01 · Core discipline

Serving Infrastructure at Scale

Sub-200ms global delivery across 535K pages with a nightly full-fleet rebuild. The nervous system that keeps every other surface honest.

02 · Core discipline

Edge + Backend-for-Frontend Architecture

Coupled the backend service to the hosting layer when the standard advice says decouple — and eliminated three problem classes at once: no exposed endpoints, server-rendering plus caching, lower hosting cost.

03 · From aerospace

Systems-Engineering Rigor

Aircraft-performance pipelines where a wrong number means the plane falls. That floor became the floor he ships commerce infrastructure from.

04 · From aerospace

Hardware-Software Boundary Reasoning

A computer-engineering specialization at the seam between hardware and software — the lens behind every edge-vs-origin and cache-store decision.

05 · How he ships

Multi-Problem Architecture

Decisions that close several concerns at once rather than solving them in sequence. Pattern recognition, not cleverness — the alternative is a year clearing tech debt.

06 · How he ships

Build-for-Change Direction

Frameworks built backend-agnostic from day one. The framework is the deliverable; the current consumer is incidental.

The career

Aerospace to AI commerce — one through-line: build the substrate the work runs on.

2020 → Now · Product.ai
Product.ai (formerly Demand.io)
Lead Architect, Serving Infrastructure
Left aerospace to architect the serving infrastructure that carries Product.ai’s cash engine. The page-serving layer now delivers 535K SimplyCodes merchant pages at sub-200ms global P95, rebuilds the full fleet nightly, and holds a 99.9% uptime floor. Shipped the backend-for-frontend + edge pattern other engineers cite as the reference, and a sub-second cache-invalidation pipeline that collapsed the staleness window from hours to seconds.
Sub-200ms · 535K pages · 99.9% uptime
Before Product.ai
Several years · Northrop Grumman
Northrop Grumman
Engineering Systems Engineer
Built engineering design-tool suites and aircraft-performance analysis pipelines at one of the largest aerospace and defense companies in the world. The rigor of “wrong number → plane falls” became the rigor he ships SimplyCodes with.
Engineering tools · aircraft performance
Santa Clara University
Santa Clara University
MS, Computer Engineering
Graduate specialization at the seam between hardware and software — the discipline that still shows up in how he reasons about edge-vs-origin tradeoffs and storage architecture.
Hardware-software boundary
Santa Clara University
Santa Clara University
BS, Math + Computer Science (dual major)
Dual-major undergrad — CS-first thinking on a math substrate. Earlier still, he and a friend built a Minecraft mod with nothing but an idea, excitement, and a Java de-obfuscation tool. The instinct to reverse-engineer a runtime in order to extend it started here.
Dual major · Math + CS
Loyola High School (Los Angeles)
Loyola High School
Eagle Scout · Highest Honors graduate
Eagle Scout — the rank roughly 6% of Scouts earn — and a Highest Honors graduate. Service-track volunteering in food distribution. Structured discipline and a service orientation still visible decades later in how he runs production infrastructure.
Eagle Scout · Highest Honors
How he thinks

Front-load the problem. Build for the next environment.

Isaac’s method has two halves, and they’re load-bearing in opposite directions.

Front-load problem discovery — understand the full shape before building, or you find the gaps mid-execution. It’s why he caught a silent cache-normalization bug in the same session he introduced it: he was already looking for it.

Build for change — modular enough to react when the environment shifts. His cache-invalidation framework was backend-agnostic from day one; whatever owns the underlying data in two years won’t have to ask permission to plug in. The through-line is decisions that close multiple problem classes at once — pattern recognition from twelve years of aerospace and serving infrastructure, not cleverness.

My best architectural work happens when I can validate an approach that hasn’t been done before at the company — and it turns out to be the right framework for the situation. Isaac, on what good architecture looks like
Operating code

Four principles that show up across his shipping.

01 Diagnosis

Cure over symptom. Always.

Pressure to rush to an outcome without time to diagnose is what kills his work. When the cure lands, it stays landed.

“I’d rather spend the proper time on the cure than keep treating symptoms.”

02 Architecture

Decisions that close multiple problems at once.

Backend-for-frontend coupled to the host. A backend-agnostic event pipeline. A per-merchant template router. Each is one decision that solved several concerns simultaneously.

“Design decisions that address multiple concerns at once, rather than solving them sequentially.”

03 Verification

Don’t trust a 200. Verify the work actually landed.

A nine-month-dead pipeline and a silent cache mismatch are the same lesson: a plausible-looking response you didn’t inspect is the most expensive class of bug.

“The only way to catch a 404 that looks plausible is to actually request the URL and check.”

04 Direction

Build for the next environment, not this one.

His cache-invalidation framework was backend-agnostic from day one. The framework is the deliverable; the current consumer is incidental.

“The framework is intentionally backend-agnostic. The serving layer won’t need to change when that swap happens.”

What he owns

What he owns — and what he intentionally does not.

The anti-goals list is part of the architectural artifact. It’s why the infrastructure stays load-bearing instead of sprawling.

The page-serving environment

accountable

The sub-200ms global serving substrate carrying 535K SimplyCodes pages.

The nervous system every other surface depends on. If it’s slow or stale, the cash engine is slow or stale.

The backend-for-frontend + edge layer

accountable

Backend service tightly coupled to the host; cached at the edge.

No exposed endpoints, server-rendering plus caching, lower hosting cost — security, speed, and cost solved in one decision.

The cache-invalidation pipeline

accountable

Backend data changes reach the live edge in seconds, not hours.

Background rewarm after eviction, so visitors never see a cold miss. The staleness window collapsed from hours to seconds.

The per-merchant template router + nightly rebuild

accountable

Runtime per-merchant toggling, instant rollback, full fleet refreshed nightly.

Any degradation reverses per merchant in seconds — no fleet-wide blast radius — with 100K+ pages refreshed without manual intervention.

Anti-goal: business logic in the serving layer

anti-goal

Revenue rules, merchant categorization, and archetype logic are owned elsewhere.

Baseline-first: prove stack and template performance before layering business logic in. He builds the path, not the truth that travels it.

What sets him apart

Four combinations rare individually. Unusual to find in one engineer.

Aerospace rigor applied to AI commerce

A discipline built where a wrong number drops an aircraft, now running 535K commerce pages. The floor he ships from is higher than the ceiling most teams reach for.

Substrate-builder, not feature-builder

Most engineers build the work. Isaac builds the thing the work runs on — the serving layer, the pipeline, the router — so everyone else moves faster.

Multi-problem decisions as a default

Backend-for-frontend coupling, a backend-agnostic event bus, a per-merchant router. Each is one move that closed several problems — the opposite of incremental.

The anti-goals list as an artifact

Knowing precisely what NOT to own is why his infrastructure stays load-bearing instead of sprawling. Discipline is the architecture.

Career history — Eagle Scout, Santa Clara degrees, and the aerospace background — is publicly verifiable. See the record →
The through-line

Aerospace rigor applied to AI commerce. Build the substrate the work runs on. Ship the framework, not the feature. The 535,000 pages are the receipt.

Product.ai builds with engineers like Isaac — people who build the substrate everyone else moves on. See open roles →

Get in touch with Isaac See the team