Full stack engineer · Austin, TX · open to remote
I build the whole site,
from the React component
to the server behind it.
Full stack software engineer at GoDaddy. About half my work is React and TypeScript, half is the server-rendered Node.js layer behind them, on a site that serves three brands. I also built the GitHub Actions automation that ships it.
- 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.
I work across that whole chain, about half on the frontend and half on the server: the Node.js transforms and service integrations, the component interfaces, the rendering behavior, and the CDN delivery that puts it in front of people. In my first year I built and unit-tested features in the .NET Core (C#) services behind the site.
- Contentful
- Node.js servertransforms · service calls
- Component mapping
- SSR render + hydrate
- Brand surfacesGoDaddy · Afternic · 123 Reg
integrations with other GoDaddy services and CDN delivery
3
brands on the shared platform
$1M+
yearly revenue driven by a domain page I rebuilt
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.
I also own how it ships.
The shared library publishes several times a day and the site consumes it about as often. Here is what that used to cost, and the GitHub Actions automation 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
100+
CI workflow runs on an active day
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
I was hired to write React and placed on the team that owned the site's .NET Core (C#) services, because that is where the need was. I learned C# on the job and spent the year building and unit-testing features in those services.
I rebuilt a gTLD domain product page that drives more than $1M a year in revenue, moved the domain experiences from class components to hooks, and extended the TLD-availability and domain-purchase integrations behind them.
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.
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.
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.
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.
About
I learned the stack by going where the work was
I was hired to write React. The first real need was on the team that owned the site's .NET Core services, so I spent my first year learning C# there. Since then I've worked across the whole site: components, the server layer, the integrations, and the pipeline that ships it.
What ties it together is leverage. A feature ships once; a shared component, a service integration or a release workflow gets used for years. It's also why I wrote and taught a four-hour React bootcamp 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 engineering 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
Frontend
Backend
Delivery
Let's talk