A Unified Whole

At AUW Studio, the difficult part was translating a brand into software without flattening either side.

Jeff Visoky led the brand and web design across the studio work. He gave me the brand systems and page designs; I was responsible for translating them into working, maintainable software.

The projects also had a real progression. ParaNano came first as a Next.js product site, followed by more involved Shopify work for Spicy Dan and Who Decides War. Each project exposed a different part of the same translation problem.

Client projects arrived with different visual languages, product catalogs, merchant habits, deadlines, and levels of technical maturity. A fashion storefront, a jewelry configurator, and a biotech product site could all need React or Shopify, but that did not make them the same engineering problem.

My role sat between design intent and implementation. I had to identify which parts of a concept were structural, which were content, which needed to remain editable by the client, and which interactions would break once real products, variants, media, or mobile navigation entered the page. That translation work often decided the architecture before a framework did.

The goal was not to make every client look like one studio template. It was to reuse the engineering discipline underneath the visible differences: clear design tokens, composable sections, predictable content schemas, responsive primitives, and deployment workflows that another engineer or merchant could understand.

The Shopify work grew around a reusable Liquid and Tailwind foundation rather than repeated edits to stock themes.

The base structure separated layouts, JSON templates, sections, snippets, assets, and locale or configuration data. Reusable buttons, cards, media wrappers, navigation pieces, product grids, cart fragments, and newsletter components gave each storefront a vocabulary. Brand-specific typography, spacing, color, and image behavior sat on top of that vocabulary instead of being scattered through unrelated files.

Liquid imposed a useful constraint: the page had to work with Shopify objects and merchant-editable schema, not with data shaped for a one-off mockup. A collection card needed sensible fallback behavior. A product surface had to reflect selected variants, availability, prices, media, and cart semantics. A homepage section needed to survive being reordered or populated differently in the theme editor.

That made the work closer to product engineering than static implementation. Every custom surface had two users: the shopper interacting with it and the merchant maintaining it after handoff.

The most polished brand work was usually the most demanding on browsers and data.

Large imagery, native and hosted video, mobile-specific assets, product galleries, overlays, expandable menus, and animated collection blocks had to coexist with page performance and basic shopping behavior. Desktop hover states were not enough. Touch targets, scroll locking, swipe behavior, focus, viewport height, and mobile cart or menu state all needed separate attention.

On media-heavy themes I built scripts and mappings around product videos, including staged Shopify uploads, desktop and mobile metafields, rate limits, and first-frame handling. That moved repetitive asset work out of manual admin clicks and made the relationship between a product and its media explicit.

The 3D product work pushed the boundary further. Shopify collection and variant data had to drive a browser-side configurator, model nodes and materials had to match sellable options, and the resulting selection had to reach the cart as a coherent bundle. It was a visual experience, but it still depended on identifiers, availability, loading state, and failure behavior being correct.

Most of the real iteration happened after a page already looked finished at one width.

Headers that overlaid a hero needed different contrast and background behavior after scrolling or navigating to an interior page. Nested menus that felt natural with a pointer could become awkward on a phone. A product-media layout could look editorial on desktop and become unusable when thumbnails, video, and purchase controls competed for a narrow screen.

The repositories show the unglamorous work that made those experiences hold together: mobile dropdown fixes, cart corrections, sold-out and sale states, content-height adjustments, image and video handling, search behavior, and large-product-screen fixes. Those commits rarely changed the portfolio headline, but they are where a branded interface became a usable storefront.

I learned to treat responsive work as a change in interaction model, not a sequence of shrinking widths. The same content and business rules remained, but navigation, media controls, disclosure, and ordering had to be reconsidered for the device.

Shipping across several brands made me faster without making the work generic.

The reusable part was never the finished page. It was the ability to find the stable boundary: a section schema, a media primitive, a cart contract, a model adapter, or a deployment path. Once that boundary was clear, the visible implementation could be specific to the client without becoming fragile.

Client work also made communication part of the technical loop. A merchant needed to know which content could change safely. A designer needed to see where browser or commerce constraints affected an interaction. An engineer taking over the theme needed structure and naming that explained the intent without a meeting.

That experience still informs my backend and systems work. A system is easier to operate when its boundaries are explicit, but those boundaries are only useful if they match the people and workflows around the code.