Most of what’s here started the same way: the standard playbook had run out, and what the
business needed didn’t exist yet. That’s the shape of this practice — most engagements
begin with a problem nobody ships a product for, and the build is designed around it.
So read these as evidence of the
four practice areas
working together: real-time integration, extension apps, analytics, and AI applied to
real production problems.
Custom doesn’t mean one-off, though. Everything here was built for scale and to SaaS
standards — documented, redeployable, and in some cases deliberately architected so it
could be delivered again. That phrase isn’t a metaphor: one entry below is a SaaS
product I build and operate myself. If one of these sits close to your problem — or
is your problem — that’s a great conversation: a proven design, redeployed as
your own build, in your cloud, owned by you. And if none of them match, what they
demonstrate is the capability that gets applied to your version.
National biopharma services network · several hundred US sites
From $1.4M in validated labor savings to the platform that captures it
The problem
An executive sponsor had a mandate to find $1M+ in recoverable labor cost ahead of a UKG Pro WFM transformation. The labor standards in use were inherited documentation nobody had re-checked against what the process actually did, and site productivity was measured as volume per labor hour — a number that conflates how busy a site is with how well it runs. Every prior savings estimate had died the same way: an executive asked one hard question and it didn’t survive.
What I built
- Earned-hours labor standards rebuilt in PySpark from actual process timestamps rather than the inherited documentation, with time adders for the visit types that genuinely cost more labor
- An earned-to-actual hours ratio counting every hour a site consumes, including non-production time, so the metric can’t flatter itself — and deliberately never called an “efficiency score,” so nobody read it as a verdict on their people
- Two opportunities taken all the way to defensible: labor burned before sites open, and capacity held open past demand — each modeled with the real operational wind-down before a single hour was counted as recoverable, then backtested against service levels
- A wait-time overlay proving the over-staffed sites weren’t buying customer experience with the extra labor — the step that turned a cost recommendation into one operations could actually accept
- Pareto prioritization concentrating rollout on the ~30% of sites carrying 80% of the opportunity, turning a several-hundred-site problem into a targeted plan
- Then the platform: UKG Pro WFM Data Hub Premium landing into the client’s Databricks lakehouse zero-copy via query federation — no ETL, no duplicate storage, one governance layer — with source-of-truth ownership settled per subject area so the client’s own labor logic survived the move
What it proves
The analysis and the implementation are both ordinary skills; doing both is the rare part. Because the number came out of their own punch, schedule, and volume data in code, the findings arrived at the implementation team already quantified — configuration requirements, not a deck that gets filed. And the model was deliberately held to the narrower of two labor pools, understating the opportunity by an estimated 40–60%: a number a client cannot argue down is worth more than a bigger one. That discipline — actuals separated from modeled, confounded days excluded rather than explained away, findings backtested before they’re presented — is what transfers to your labor question, whatever the industry.
Global travel-retail operator · thousands of employees, multiple countries
An event-driven variable-pay platform
The problem
Tips earned at the register needed to become payroll dollars — but the pooling and allocation rules were too complex for the POS or payroll system to model, no standard interface covers the collision of POS, timekeeping, and payroll, and the spreadsheet process ran days behind the shift with no audit trail.
What I built
- Event-driven pipeline consuming POS transactions and UKG punch data, calculating tips continuously as shifts happen
- Allocation rules as effective-dated configuration — per-location variants without code changes
- A manager approval app gating payroll sync: approved is the only thing that syncs
- Idempotent, fully audited payroll writes with drill-down from every pay line to its source transactions
What it proves
This is what “custom” means at full depth: real-time orchestration across UKG and non-UKG systems, an extension app standing in front of payroll, and human-in-the-loop controls — engineered to SaaS standards, multi-country from day one. If variable pay is exactly your problem, this design is a proven head start ready to be redeployed as your own build. If it isn’t, the range it demonstrates is what transfers to your version of “nobody builds that.”
Multi-site childcare operator
Demand signals feeding UKG Pro WFM Forecasting
The problem
Schedule quality depended on a demand signal — intraday occupancy — that lived in an operational check-in system UKG had never heard of. The forecast was effectively running on a stub while the real driver sat unconnected.
What I built
- Transformation of raw check-in events into intraday occupancy curves, per site and per interval
- Volume drivers loaded through the UKG Pro WFM Forecasting API on a repeatable, monitored warehouse pattern
- Historical backfill so the forecasting models trained on real demand history, not a placeholder
What it proves
The source system was unusual; the discipline is universal. Any operational signal — POS transactions, bookings, foot traffic, production counts — can be shaped into forecast drivers the same way, and the pattern itself is repeatable. What makes it work is knowing exactly what Pro WFM Forecasting needs and how to feed it reliably.
Global apparel retailer
Schedule-effectiveness analytics on UKG Data Hub
The problem
Leadership wanted to know whether store managers actually trusted the auto-scheduler: how much of each generated schedule got reworked, where, and at what times of day. No canned report measures that.
What I built
- KPI models built directly on Data Hub’s BigQuery layer, comparing generated schedules against what managers actually posted
- Rework metrics by store and by daypart, so the answer was operational, not anecdotal
What it proves
When leadership asks a question no report answers, the data usually already exists — the gap is modeling. I was Data Hub’s product architect, so I know what its structures can be pushed to do; the same custom-KPI capability applies whether your question is schedule trust, earned hours, or overtime drivers.
WFM Labs R&D · working tools, not concepts
AI agents for UKG configuration and data
The problem
The AI question in workforce management isn’t “can a chatbot answer questions” — it’s whether an agent can safely do real work against a platform as configurable as UKG: provision settings, navigate a data model with thousands of fields, generate correct SQL.
What I built
- A configuration assistant that provisions UKG settings through curated API definitions — the agent can only do what the definitions allow
- Data-model agents that generate SQL over a semantically indexed data dictionary, grounded in the actual structures
- Guardrails as architecture: curated action surfaces, grounded retrieval, and audit logs on every generation
What it proves
AI-enablement claims are cheap; these run. The pattern — ground the agent in your real configuration and data dictionary, constrain what it can touch, audit what it does — is exactly what I deploy for clients, scoped to their environment and their governance.
My own product · joinsorrel.com
Sorrel — a SaaS platform I built and run
The problem
Volunteer-run non-profits drown in disconnected admin tools: spreadsheets for members, a payment page for dues, email threads for events, a website nobody knows how to update. Sorrel consolidates all of it into one platform a volunteer board can actually run.
What I built
- Multi-tenant SaaS: member management, online dues with automatic renewals, event RSVPs and check-ins, board governance tools, and an AI-assisted website builder
- Sprout, the built-in AI assistant: drafts board minutes, generates event pages, and updates websites from plain-text descriptions — every change gated behind human approval before it publishes
- The full operating surface of a real product: subscription billing, tenant isolation, third-party integrations, monitoring, and support
What it proves
This one isn’t a client engagement — it’s the standard the client work is held to. When I say a build is “engineered to SaaS standards,” I mean standards I live with as an operator: uptime someone notices, billing that has to be right, AI features that ship behind approval gates, tenants that never see each other’s data. And it sits outside the WFM space entirely — the engineering discipline is portable.
Have your own version of “nobody builds that”?
Bring it to a 30-minute working session. If it’s genuinely not worth building, I’ll tell
you that too.
Get in touch