Austin, TX · open to remote
I build the site,
and the machine
that ships it.
Software engineer at GoDaddy on the platform behind our customer-facing web experience — Contentful-driven, server-rendered, three brands — plus the release automation that gets it to production safely.
- Shared packages I maintain
- Rendering layer
- Brand surfaces
The platformGoDaddy · Afternic · 123 Reg
Content goes in one end. A multi-brand website comes out the other.
Editors author structured content in Contentful. It gets transformed and mapped onto a shared React and TypeScript component library, rendered server-side, and served as the customer-facing site across GoDaddy, Afternic, and 123 Reg — with routing, navigation, search, brand configuration, and internationalization all resolved along the way.
My team builds and maintains that chain. Not one application at the end of it — the transforms, the component interfaces, the rendering behavior, and the integrations with the other systems and the CDN that put it in front of people.
- Contentful
- Transform / facade
- Component mapping
- SSR render + hydrate
- Brand surfacesGoDaddy · Afternic · 123 Reg
integrations with other applications and CDN delivery
3
brands on the shared platform
100+
CI workflow runs on an active day
RTL
internationalization, including right-to-left
Internationalization
Right-to-left layout and translation handling inside components that several brand experiences consume. A shared component can't assume the direction text runs.
React 18 → 19
Contributed to moving the shared platform onto React 19 — working the breaking changes across the component library and the applications that consume it, without a flag day for the teams downstream.
Content-to-component alignment
Contributed to keeping component interfaces aligned with Contentful content schemas, so a content-model change and the component that renders it don't drift apart silently.
About a third of my time goes here.
A platform this size releases constantly — the shared library publishes multiple times a day, and the site consumes it about as often. Below is what that used to cost, and what I built to stop paying it.
My manager and our technical program manager point people at me as the team's subject-matter expert for developer experience and CI/CD.
Case study 01GoDaddy · 4 repositories
Every release used to be walked across four repositories by hand.
So I built the thing that walks it. Press play.
- Someone has to do this
- The machine does this
Idle
Ready
Human touchpoints
11
Steps
15
The actual hard part
Reconciling state, not opening PRs
Releases overlap. Related packages travel in synchronized groups. A naive consumer opens contradictory branches — so the system computes the newest valid group before it emits anything downstream.
Deploys stopped batching
Teams had been deferring releases rather than hand-trace package ownership. Removing the handoff removed the reason to wait. Early adoption merged 14+ automated bumps.
A defect class closed
Shared-package versions used to ship decoupled from the changes they belonged to. Reconciliation makes that state unrepresentable.
The merge stayed human
Deliberately. The system generates a validated draft PR and stops.
20–40 min
of manual coordination removed per propagation
13
packages in a representative build
3
brands on the shared platform
daily+
release cadence the automation keeps up with
Why it mattered
The manual step wasn't slow. It was a way for broken combinations to reach production.
Some packages only work at matched versions — they have to go out together or not at all. A human doing that by hand, several times a day, will eventually get it wrong.
One missed pairing
Runtime failures, not build failures
A mismatched pair often compiles fine. It breaks in the browser, on real traffic, where the first person to notice is a customer.
Visual and behavioral drift
Half-updated shared components render inconsistently across brands and pages — the kind of bug that gets filed five separate times before anyone traces it to a version.
Nothing was watching for it
Versions could ship decoupled from the changes they belonged to with no check that would catch the drift. Diagnosis started from the symptom, hours downstream.
The cost of the blast radius
These are storefront and purchase surfaces for a company that sells continuously, worldwide. Minutes of a degraded checkout path are expensive in a way a release ticket never captures.
I won't put a dollar figure on it — I never instrumented one, and I'd rather say that than invent it. What I can say precisely: reconciliation makes the broken combination unrepresentable. The system can no longer emit a version set that doesn't hold together, so that whole class of production incident stops originating here.
Also on my deskon desktop, tap any row
Six more systems
Producer repo emits standard release metadata, a central layer validates it, and the downstream repo or deployment path picks it up. Repeated release logic lives behind reusable workflows and composite actions instead of being copy-pasted into every repository. Existing pipelines plug into it rather than being rewritten.
A merge queue evaluates a temporary merge-group state, not the PR head — so required checks have to understand that path or they are validating the wrong thing. I made merge-group validation correct first, then cut waste: selective execution, cancelling superseded runs, and reusing cached build output.
Theme and intent abstractions that separate behavior and semantics from brand presentation, so shared React infrastructure serves several brand experiences without forking a component per brand.
The CMS could render three sticky navigation elements as separate React roots, so top: 0 made them collide — no shared parent owned the layout. I built a portal-based stacking surface with a registry, deterministic ordering and measured dynamic offsets, exposed to product teams as a single hook.
I contributed to the Sitecore to Contentful modernization on the shared rendering layer: content transforms, a facade and component map, and shared packages that behave the same on the server as in the browser — no assumed window, no hydration surprises.
Four hours, a progressive repository with structured branches, exercises and live instruction for interns. Turning what I know into something the team keeps is the same instinct as building a platform, just aimed at people.
About
I kept drifting toward the layer underneath
I started in product-facing React work, but the things I kept volunteering for were one layer down. The word for what I'm after is leverage: a feature ships once, a platform gets used for years.
That thread runs through all of it — shared component architecture, theme and intent APIs, sticky-stack, release orchestration, merge queues, the bootcamp I wrote for interns.
I'm also careful about what I claim. If I tell you a system saved time, I'll tell you how I'd measure it — and where I haven't yet. That habit has made me better at platform work than any framework has.
The trajectory
GoDaddy
Jan 2025 — nowSoftware Development Engineer II · Remote
GoDaddy
Jul 2022 — Jan 2025Software Development Engineer · Remote
Revature
2021 — 2022Software Engineer · Verizon engagement
M.B.A., IT Management
Western Governors University · 2025
B.S., Computer Science
CSU Monterey Bay · 2022
Toolkit
Let's talk