Partner operations inside the Account Application

The 45HomeLab partnership needed more than a launch announcement. It needed a working operational bridge between hardware sales, customer ownership, Unraid account state, warranty context, support handoff, OEM provisioning, and the prebuilt shop sitting in front of all of it. When a customer buys a partner-built Unraid system, the support experience depends on whether the right system and purchase facts are already in front of the people who need them.

I built and ran the Account Application side of that bridge. I structured the work as a phased partner program instead of a single integration.

A phased partnership, not a single integration

We ran the 45HomeLab program in five named phases: R&D, Pre-Production, Deposit, Launch, and Post-Launch. I owned the engineering and product side of each one. That structure mattered because partner hardware is not a one-shot integration. It needs a recurring product and support loop, so I scheduled and ran Quarterly Product Meetings with the 45Drive team on a 1-of-4, 2-of-4, 3-of-4, 4-of-4 cadence. Product and support concerns kept feeding back into the program after launch. I also ran roadmap and platform-direction briefings for the partner, so they were not learning about upcoming FeatureOS work at the same time as the public.

What I worked on

Account Application partner module

• Partner API intake that pulls in customer and purchase information at the point of sale or shipment.
• A partner module inside the Account Application for integration status, partner metadata, and support visibility.
• Support-facing views for customer identity, system serial, model, purchase date, warranty date, and parts-list context, so a support operator can answer “who owns this system, what did they buy, is it still under warranty, and which team takes the handoff” without re-asking the customer.
• Data-matching logic between partner-submitted hardware records and Unraid account or system records, plus operator dashboards for import health, unmatched systems, warranty coverage, and support handoffs.
• Coordination with partner order management so data shows up at the right point in fulfillment, not after the fact.
• Demo and validation flows that proved support could find the correct customer and hardware context from the Account Application end to end.

OEM provisioning and USB installer

Partner work pulled out concrete tooling requirements that did not exist in the consumer product:

• Plugin setup was painful for OEMs, so we wrote scripts and tooling that install the right plugins onto bootable Unraid drives without an operator doing it by hand.
• Activation-code logic was hard to use at OEM volume, so the workflow needed bulk and OEM-style activation paths inside the Account Application instead of a manual workaround.
• A 45HomeLab USB installer with a 90-day review checkpoint, scoped against the actual hardware launch timing rather than a generic OEM milestone.

Prebuilt shop launch

• A prebuilt shop on unraid.net so partner-built systems had a real consumer storefront, including the edits and operational work inside Craft CMS that backed it.
• Phased launch tracking across the Pre-Production and Launch phases, with explicit gates rather than an open-ended “check in when it’s done.”

Technical shape

The integration had to be simple enough for a partner engineering team to implement and strict enough for Unraid to trust the data in support workflows. I designed around explicit fields, predictable submission timing, and support-oriented views instead of exposing a general-purpose internal system.

The Account Application was the right home for this work because it already sits next to account ownership, order context, license workflows, and support tooling. Partner data did not need to become a separate side database with a separate operator workflow. It needed to add to the account platform so support could answer practical questions fast.

The dashboard model mattered too. Partner integrations fail in small ways before they fail in large ones: a missing serial, an unmatched customer, a warranty date that does not line up, a parts list that has not arrived, or a support handoff with too little detail. A useful operator view makes those states visible before they turn into customer confusion.

Outcome

The result is partnership infrastructure that behaves like product infrastructure. Marketing can talk about the partnership, partner engineering has an integration path, support has customer and hardware context, and the Account Application has a reusable pattern for partner-submitted operational data. The OEM tooling pattern (bulk activation, USB installer provisioning, parts and serial and warranty visibility) gives us a template for the next partner, OEM, MSP, or multi-system account workflow we take on.

Most of this work is quiet in day-to-day use. A support operator can answer who owns the system, what was purchased, when the warranty started, which serials are in play, and which handoff path applies. A partner team can send data into an agreed interface. A customer does not have to explain how the two companies relate to each other. It’s the difference between a partnership that’s a real product experience and one that’s a launch page with manual work behind it.