MagTek Platform

The setting

I own 100% of the full stack across all eleven MagTek sites on the shared platform: MagTek.com, Magensa, the hardware product line, the support portal, and the related properties. The platform is a long-running ASP.NET MVC system that can’t be rewritten. The job is to understand it, stabilize it, and change it in place.

The full stack

I work across the application layer: ASP.NET MVC and C#, Razor views and typed partials, Entity Framework data access, CSS and design tokens, front-end code, and production migrations. A change that needs a controller, a view model, a query, a template, or a stylesheet stays in the same workstream.

The platform is production-critical. I keep the existing stack coherent while it changes under live traffic.

What platform work means

A change is usually a pattern that has to work on every existing page and every future one.

That includes:

• A shared component library on Razor partials. Detailed below.
• A rebuilt CSS foundation built on design tokens.
• Navigation patterns that work across properties that were never designed to share an identity.
• Performance work that respects the integrations the business depends on.

Most of this work is invisible when it works.

A component library on Razor partials

ASP.NET MVC doesn’t ship a native component model. Razor partials do, if you treat them as components instead of as include directives.

The library now sits at 100+ shared components: primitives (button, card, badge, breadcrumb, sticky sub-nav), content blocks (hero, metric row, comparison table, feature grid, callout), and layout shells (page chrome, product-page templates).

Each one is:

• Modular. One responsibility per partial. The card is the card. The hero is the hero. Nothing knows about anything it doesn’t have to.
• Strongly-typed. Every partial declares a ViewModel. Calling it from a Razor view is type-checked, the parameters are visible to IntelliSense, and a missing required field is a build error rather than a runtime surprise.
• Dynamic. Partials take parameters, render conditional regions, and compose. A hero can wrap a CTA component which wraps a button component, and the consuming view gets the typed contract for the whole stack.
• Reusable. The same hero partial drives the homepage, every product category page, the support portal landing, and Magensa’s surfaces. Once with brand variants, once with structural variants, never duplicated in markup.

That is what makes a single change reach many pages. Updating the spacing on the hero updates ~30 surfaces at once. Renaming a CTA prop is a compile-time error in every consumer until it’s fixed. The platform becomes a system instead of a stack of one-off pages.

Most of the work was extracting patterns that already existed, turning them into partials with sensible defaults, then moving consumers without touching production traffic.

Modernization at the system level

Every public surface across MagTek and the related sites runs on the application layer, components, tokens, layout primitives, and conventions I built and own. A change at the system level propagates everywhere at once. A new visual treatment lands across the whole platform without a single per-page edit. A renamed prop is a compile-time error in every consumer until it’s fixed.

Mechanically:

• CSS rebuilt as a real design system. Spacing, color, type, radius, shadow, motion, all pulled into tokens. Surfaces adopt them incrementally on their own timeline. No flag day, no rewrite, just compounding consistency as each surface migrates.
• Layout primitives instead of bespoke layouts. A small set of layout shells (page chrome, content rails, sticky sub-nav scaffolds, card grids) replaces a long tail of one-off CSS. The same shells run the marketing surfaces, the product line, the subsidiary brand, the support portal, the developer pages.
• Navigation across sites. Header behavior on scroll, breadcrumbs, sticky horizontal sub-navs, mobile drawers. Built once and used across properties that were never designed to share an identity.
• Typed components. Every shared component declares a ViewModel; every consumer is type-checked at build. A missing field becomes a build error instead of a runtime surprise.
• Reusable patterns. Comparison rows, metric stories, callouts, feature grids, hero variants, and CTA blocks. The partials make them easy to drop in, so the same content can render in dozens of places without copy-paste.
• Migrations. Most of the hours go into extracting patterns from existing markup safely, moving consumers over, and keeping production traffic running.
• SEO, analytics, and redirects. Internal links, sitemaps, structured data, event names, and 301 maps, all sequenced so crawlers and dashboards don’t see a break while the system changes.
• Performance. Asset budgets, the render path, image strategy, and less JavaScript. The sites serve real customers on real connections.

The screenshots below show it on specific pages.

Working with constraints

Long-running systems are risky to change. I make changes in small steps and test them against production behavior.

One example. The homepage hero ran a six-slide rotating carousel that nobody finished. The straight design call was killing the slider and replacing it with a static hero on a single message. The harder problem was around it: the half-dozen marketing surfaces sized to the carousel’s dimensions, the analytics taxonomy that named events by slide number, the stakeholders who’d argued for “their” slide. The work was sequencing it. Build the static hero on a parallel route first, run it as a measurable comparison against the live page, migrate the dependent surfaces one at a time, then retire the carousel last so nothing pointed at a dead artifact.

The design decision was a single static hero with one message. The harder design decision was about how to land it without breaking the system around it.

Other work that mattered most:

• Replacing a cluster of one-off layouts with a small set of layout primitives, without touching production traffic.
• Moving spacing, color, and type into tokens that the rest of the platform could adopt incrementally on its own timeline.
• Sequencing navigation changes so internal links, SEO, and analytics didn’t drift during the transition.