Spirit Halloween DC: Replacing UKG for $75/mo | OAG Case Study

A 500-associate distribution center replaced UKG (and the $48K–$96K/yr it costs) with a $75/month owned stack built on Cloudflare Workers and Supabase. That swap came out of an Operations Architect engagement (industry term: fractional COO). OAG ran the OIL Framework, deleted what the operation didn't own, and handed back a documented system nobody has to rent anymore. (OAG receipt: spirit_halloween.system_cost)

Why This Matters Now

Enterprise workforce management software is one of the most unexamined line items in a distribution center budget. Nobody interrogates it because it came with the building, or because the HR team set it up six years ago and nobody wants to touch it. That is exactly how a $48K–$96K annual license survives inside an operation that uses maybe 12 percent of its features.

The Spirit Halloween distribution center case is a receipt, not a pitch. A real 500-associate operation swapped out UKG for $75/month in owned infrastructure. The DC still runs. The headcount didn't change. The vendor invoice disappeared. If your WFM line item is above $20K/yr and your headcount is under 1,000, this page is worth reading carefully.

The Receipt: $75/Month for 500 Associates

Here is the number first, because that is how receipts work. A distribution center with approximately 500 associates (OAG receipt: spirit_halloween.headcount) was running on UKG. The replacement stack costs $75/month total. The delta against the low end of a UKG contract for that headcount is roughly $47,925/yr. Against the high end, it is closer to $95,925/yr. (OAG receipt: spirit_halloween.system_cost)

UKG, ADP, Dayforce, and Kronos all land in the $48K–$96K/yr range for a 500-person workforce. (OAG receipt: spirit_halloween.system_cost)
The replacement stack runs on Cloudflare Workers, Supabase, R2, KV, Resend, and Stripe. Total: $75/month. (OAG receipt: spirit_halloween.system_cost)
The DC still has approximately 500 associates on it. The headcount didn't shrink. The license cost did. (OAG receipt: spirit_halloween.headcount)
This is not a prototype. The hand-off included documentation that a non-technical ops lead can own and operate without calling OAG.
The stack is owned infrastructure. No renewal cycle. No vendor negotiation. No migration hostage situation.

The hand-off is the deliverable. A system the client cannot operate without OAG is not a finished engagement; it is a dependency we created.

For context on how that $75/month benchmark gets set: OAG runs its own entire operation on $74/month end-to-end. (OAG receipt: oag.monthly_run_cost) That number is not a marketing line. It is a live billing screenshot. The StackOS default target is $75/month because that is what a well-architected owned stack actually costs at this scale.

Why Enterprise WFM Software Bloats Distribution Centers

UKG and Kronos were built for HR departments. They were designed around compliance reporting, benefits administration, and payroll integrations that a corporate HR team needs. A warehouse floor does not need most of that. Most DC managers are using 10–15 percent of the feature set they are paying for, and the other 85–90 percent is pure cost with no operational return.

Seasonal operations pay full annual contracts for tools they run hard for 8–12 weeks. The math never worked. Spirit Halloween is the clearest example: maximum headcount for roughly a quarter of the year, full license cost for all four.
Every add-on module is a new line item. Scheduling, time-and-attendance, and compliance each bill separately in most enterprise WFM contracts.
The vendor holds the data schema. When you decide to leave, migration costs eat back years of savings. That lock-in is a feature of the vendor's business model, not a coincidence.
Approval chains inside these systems often exist because nobody ever questioned them, not because they reflect a real operational requirement.
Floor supervisors end up working around the software instead of through it. Paper lists, group texts, and spreadsheets fill the gaps the enterprise tool created.

The OIL Framework starts with Interrogate. Before anything gets cut or built, the question is: who actually owns this system, what does it actually do day-to-day, and what would break if it disappeared tomorrow? In almost every DC engagement, the honest answer to that last question is: less than you think. Learn more about what we mean by waste in the operational waste glossary entry.

Enterprise WFM vs. Owned Stack: A Direct Comparison
Factor	UKG / Kronos (500-person DC)	StackOS Owned Stack ($75/mo)
Annual cost	$48,000–$96,000/yr	$900/yr
Feature utilization (typical DC)	10–15% of licensed modules	100% (built for what you actually do)
Data ownership	Vendor schema; migration cost on exit	Operator owns the database; no exit fee
Seasonal cost flexibility	Full annual contract regardless of usage	Flat $75/mo year-round
Renewal cycle	Annual negotiation with vendor rep	None
Floor supervisor usability	Training required; workarounds common	Built for phone-first, floor-level use
Failure path documentation	Vendor support ticket	Operator runbook (DefaultFail mapped)

OIL Framework: What Got Cut Before Anything Got Built

The OIL Framework runs in one order: Interrogate, Delete, Simplify, Automate. That order is non-negotiable. You never automate before you delete. If you skip straight to building, you are automating waste, and automated waste is just faster waste. The Spirit Halloween engagement followed this sequence exactly.

Interrogate. Mapped every workflow the DC actually ran inside UKG versus every module on the contract. Most of the contract was unused or duplicated by workarounds the floor team had already built in spreadsheets and group chats.
Delete. Removed integrations, modules, and approval chains that existed because nobody had questioned them. If a workflow couldn't be traced to a specific operational output, it got cut. No sentimentality, no committee.
Simplify. Collapsed what remained into forms a floor supervisor can fill out from a phone. Scheduling input, time exception logging, and compliance records all simplified to single-screen inputs.
Automate. Wired the simplified inputs into the owned stack. Notifications route through Resend. Records write to Supabase. Nothing needed a vendor to maintain it after go-live.

The Interrogate phase is where most DC managers get surprised. When you actually trace which UKG features generate a real operational decision, the list is short. Scheduling and time-and-attendance are the core. Everything else is cost. The operational excellence glossary has more on what interrogation surfaces in practice.

You never automate before you delete. Automating waste doesn't fix it; it just makes the waste faster and harder to see.

The Delete phase is where savings get made, not the Build phase. By the time we got to Automate, the scope of what needed building was a fraction of what UKG had been billing for. That is the OIL sequence working as designed. Read the full framework breakdown on the StackOS page.

The $75/Month Stack: What Runs the DC Now

The stack is not experimental. Every component is in production at significant scale independently. The choice of each tool came out of the Architect stage of StackOS: pick the component that does one job well, costs near zero at DC scale, and does not introduce a new vendor dependency.

Cloudflare Workers handles edge compute, routing, and lightweight API logic. There is no server to provision, patch, or monitor. It scales automatically and costs effectively nothing at DC transaction volumes.
Supabase runs the database layer: associate schedules, time records, compliance logs, and exception flags. It is Postgres underneath, which means the data is portable and any developer can read it.
R2 stores shift documents and compliance records at near-zero cost. No egress fees, which is where S3 costs compound quickly at high read volumes.
KV handles low-latency lookups: active shift state, current floor headcount, and supervisor assignments.
Resend handles transactional notifications. Schedule drops, exception alerts, and shift confirmations go out without an ESP contract or a marketing platform in the middle.
Stripe is in the stack for any payment or deposit workflows; not every DC needs it, but the architecture includes it as a default component.

The total is $75/month. (OAG receipt: spirit_halloween.system_cost) That is not a teaser price that scales up. It is the actual monthly bill for a 500-associate operation. Compare that to the StackOS Framework PDF at $29 for the self-serve audit, which walks you through how to scope a replacement stack before you commit to a build session.

One thing worth saying directly: this stack does not try to replicate UKG. It replaces the 10–15 percent of UKG that the DC actually used, built in a way the ops team can own. The other 85–90 percent of features that disappeared from the invoice? Nobody noticed they were gone.

The Hand-Off: What "Done" Looks Like in an Operations Architect Engagement

The Axis Method is a five-stage process: Diagnose, Stabilize, Document, Hand-off, Compound. The engagement does not end at Build. It ends at Hand-off, and Hand-off means the client's ops lead can run the system without calling OAG. That is the standard. If OAG is still essential at month twelve, the engagement failed. That is not a disclaimer; it is the stated design.

Diagnose. Map the current state. Surface the waste. Identify what is load-bearing and what is just habit.
Stabilize. Stop the bleeding before rebuilding. In the Spirit Halloween engagement, this meant documenting the existing UKG workflows in plain language before touching anything.
Document. Write the runbook before the build is done. Documentation is not an afterthought. It is the output that makes Hand-off real.
Hand-off. The DC received a runbook that any ops lead can follow without a technical background. Stack architecture, failure paths, escalation logic, and a 30-minute onboarding script for new scheduling coordinators.
Compound. After hand-off, the freed cost and freed ops capacity compound into the next improvement cycle. The engagement does not drag on; the gains do.

The DefaultFail principle ran through every build decision. Before anything went live, every failure mode was mapped: what happens if Supabase returns an error, what happens if a notification fails to send, what happens if the Cloudflare Worker hits a timeout. Each failure path has a documented response. The ops lead does not call OAG; they follow the runbook. That is what DefaultFail produces in practice.

Cedric's background covers Amazon, International Paper, Spirit Halloween, Maersk, and Levi Strauss, with roughly $3B+ in operational impact across that decade. (OAG receipt: cedric.career_summary) The Axis Method was built from that experience, not from a consulting framework someone sold us. See the full engagement description on the Operations Architect page.

What This Means If You Run a Distribution Center or Field Operation

This case is not specific to Spirit Halloween's seasonal model. The interrogation applies to any operation where the WFM line item is over $20K/yr and headcount is under 1,000. Seasonal operations are just the most obvious example because the math is hardest to ignore: full annual license, partial year of meaningful usage. But a year-round DC with 300 associates paying $60K/yr for UKG has the same problem. The features don't change. The usage rate doesn't change. The invoice doesn't either.

If your WFM line item is over $20K/yr and your operation is under 1,000 headcount, the interrogation is worth running. Start with the Audit stage of StackOS before committing to anything.
The StackOS Framework PDF at $29 walks you through the Audit and Architect stages on your own. It is a Saturday execution, not a multi-month project. One person, one afternoon, enough output to know whether the replacement is worth scoping.
The StackOS Build at $2,000–$3,500 is a single 3-hour live session. We build the first working version together. You leave with a running system, not a slide deck.
The Operations Architect engagement at $3,000–$7,500/month, multi-month embedded runs the full Axis Method. Diagnose through Compound. You get back a system you own, documented for an ops lead, with OAG out of the picture by design.
Every receipt on this site comes from operations at scale. Amazon. Maersk. Spirit Halloween. International Paper. Levi Strauss. (OAG receipt: cedric.career_summary) The numbers are not illustrative. They are invoices.

The OAG blog has additional case receipts if you want to see the pattern across different operation types. The blog index breaks them out by industry and stack component. The Spirit Halloween DC is one receipt. There are others.

We don't replace your operating function. We architect the system it runs on, then hand it back, documented, in 90 days. That is the engagement. If that matches the problem you have, the next step is the Operations Architect page or the $29 PDF. Either one moves you forward without a sales call.

Sources

No external sources were cited in this page. All claims are drawn from OAG internal receipts (see below) or stated as OAG operational opinion.

OAG receipts cited

spirit_halloween.system_cost: "$75/month replaces $48K–$96K/yr UKG/ADP/Dayforce/Kronos for 500 employees" (source: public site receipt)
spirit_halloween.headcount: "~500 associates" (source: public site receipt)
oag.monthly_run_cost: "$74/month total to run Obsidian Axis Group end-to-end" (source: live billing screenshot, 2026-04)
cedric.career_summary: "A decade of enterprise operations across Amazon, International Paper, Spirit Halloween, Maersk, and Levi Strauss; ~$3B+ in operational impact." (source: public bio)

Frequently asked

Can a 500-person distribution center actually run without UKG or ADP?

Yes, and the Spirit Halloween DC is the receipt. Approximately 500 associates currently run on a $75/month stack built on Cloudflare Workers and Supabase. The key insight from the OIL Framework interrogation is that most DCs use 10–15 percent of their enterprise WFM feature set. When you delete the unused 85–90 percent and rebuild only what the operation actually needs, the replacement is simpler and cheaper by a wide margin. The functions that matter, scheduling, time-and-attendance, and exception logging, are not technically complex. They became complex because they were buried inside a platform designed for a corporate HR department, not a warehouse floor.

What does a $75/month workforce management stack include?

The StackOS default stack for a distribution center includes Cloudflare Workers for edge compute and API routing, Supabase for the database layer (schedules, time records, compliance logs), R2 for document and shift record storage, KV for low-latency state lookups, Resend for transactional notifications, and Stripe for any payment or deposit workflows. Each component does one job, costs near zero at DC transaction volumes, and is owned outright. No annual contracts. No renewal negotiations. No vendor holding your data schema hostage. The $75/month figure comes from an actual production deployment at a 500-associate operation, not a pricing estimate.

How long does it take to replace enterprise WFM software in a warehouse?

The Operations Architect engagement targets a 90-day hand-off. The timeline breaks into the five Axis Method stages: Diagnose, Stabilize, Document, Hand-off, and Compound. The longest phase is usually Diagnose and Delete, because mapping what the operation actually uses versus what it pays for takes honest interrogation. The Build phase is faster than most operators expect, because the OIL Framework cuts scope dramatically before anything gets built. A StackOS Build session (the single live session offer) can produce a first working version in one 3-hour block. A full engagement with documentation and hand-off takes longer, but 90 days is the standard target.

What happens when something breaks on a $75/month system instead of a vendor-supported platform?

The DefaultFail principle answers this directly. Before any StackOS build goes live, every failure mode gets mapped and documented: what happens if the database returns an error, what happens if a notification fails, what happens if an edge function times out. Each failure path has a written response in the ops lead runbook. The hand-off documentation includes a 30-minute onboarding script for new coordinators and explicit escalation logic. The ops lead follows the runbook. They do not call OAG, and they do not open a vendor support ticket. That self-sufficiency is the point. A system your team cannot diagnose and respond to without outside help is not a finished system.

Does this approach only work for seasonal operations like Spirit Halloween?

No. Seasonal operations are the most obvious case because the contract math is hardest to defend: a full annual license for a tool you run hard for 8–12 weeks. But the interrogation applies equally to year-round operations. A 300-associate DC running year-round at $60,000/yr for UKG, using 12 percent of the features, has the same structural problem. The Spirit Halloween case is prominent because the receipt is clear and the savings are large. The OIL Framework works on any operation where the tooling cost exceeds what the tooling actually does. If your WFM line item is above $20,000/yr and headcount is under 1,000, the interrogation is worth running regardless of whether your operation is seasonal.

What does an Operations Architect engagement cost and what does it include?

The Operations Architect engagement runs $3,000–$7,500/month on a multi-month embedded basis. It covers the full Axis Method: Diagnose, Stabilize, Document, Hand-off, and Compound. The deliverable is a system the client's ops team owns and can operate without OAG after the engagement ends. That includes a documented runbook, architecture diagrams, failure path mapping, and onboarding scripts for new team members. If you want a self-serve starting point, the StackOS Framework PDF is $29 and walks through the Audit and Architect stages on your own. The StackOS Build is a single 3-hour live session at $2,000–$3,500 where we build the first working version together.

Do you need an in-house developer to maintain a Cloudflare and Supabase stack after the hand-off?

No. The hand-off documentation is written for an ops lead, not a developer. Cloudflare Workers and Supabase are managed platforms: no servers to patch, no infrastructure to provision, no DevOps function required. The runbook covers the failure paths and escalation logic in plain language. Routine operations, schedule management, time exception logging, compliance record access, are all handled through interfaces the floor supervisor uses directly. If the stack ever needs a structural change, a developer familiar with Postgres and JavaScript can work with it. But day-to-day operation after hand-off requires no technical staff. That constraint drove every build decision.

Talk through it.

If any of this is applicable to where you are, book a 30-minute scoping call. No pitch deck.

Book a call →