Custom HR Software With Shift Swapping and Overtime Rules: What It Really Costs to Build

What shift swapping actually is once real people use it

Every buyer describes this feature the same way: two employees agree to trade, a manager approves, the calendar updates. Two database rows change owners. A junior developer will quote that in a week and be technically correct.

Here is where it breaks. A retail client of ours in California ran a Saturday swap. Maria gave her 8 hour Saturday shift to Devon. Devon already had 34 hours that week, and the handoff meant he actually worked 9 hours that Saturday, taking him to 43. Hour 9 of the Saturday is daily overtime at time and a half. Three of his hours are also past 40 for the week. California does not let you pay both premiums for the same hour: the daily overtime hour comes out before you apply the 40 hour rule, so he is owed 3 overtime hours, not 4. At his rate that is $27 of premium pay on one swap, and no if statement produces that number by accident. Payroll knew none of it, because the swap lived in the scheduling table with no link to the pay period. The store manager approved it on her phone in 4 seconds against a labor budget she was measured on. The company found out 11 days later when payroll reconciled, and then found 340 more like it across 68 stores.

That is the real capability. A shift swap is a financial transaction that changes two people's projected gross pay, and the system has to know it at the moment of approval, not at the moment of payroll. Everything expensive in this build flows from that one sentence.

Overtime is a rules engine, not an if statement

The Fair Labor Standards Act baseline is simple enough to lull you: over 40 hours in a workweek, pay 1.5x. Nobody operates only under FLSA.

California adds daily overtime over 8 hours, double time over 12 in a day, and a seventh consecutive day rule where the first 8 hours are 1.5x and everything past 8 is 2x. Colorado has its own daily 12 hour rule and a 12 consecutive hour rule. Alaska and Nevada have daily 8 hour rules with different exemptions. Nevada's only applies below a wage threshold tied to the minimum wage, so the same shift is overtime for one employee and not for another standing next to them. Kentucky has a seventh day rule. Puerto Rico has its own regime entirely.

Then the local scheduling laws land on top. Oregon, and the cities of San Francisco, Seattle, New York, Chicago, Philadelphia, Los Angeles and Emeryville all have predictive scheduling ordinances that require premium pay when a schedule changes inside the notice window, usually 14 days. The critical detail nobody quotes for: most of these ordinances waive predictability pay when the change is employee initiated, which means your swap table needs a legally defensible record of who initiated what. A swap that a manager nudged an employee into requesting is not employee initiated, and that distinction is what a Seattle wage claim turns on.

A competent build does not put this in application code. It puts overtime in a versioned rules engine where each rule has an effective date range, a jurisdiction, and a deterministic evaluation over a time window. You need effective dating because when a state changes a threshold, you must still be able to recompute a pay period from eight months ago exactly as it was computed then, for an audit. You need determinism because the same input must produce the same output in the swap preview and in the payroll export, and if those two code paths differ by even a rounding rule you will ship a system that promises one number and pays another.

Practical shortcut we use: model rules as data with a small evaluation kernel, then write a golden test suite of scenarios, roughly 150 to 400 of them, one per real pattern per jurisdiction you support. That suite is the deliverable. The UI is the cheap part.

The workweek boundary problem everybody discovers late

Overtime is computed over a workweek, and the FLSA lets an employer define that workweek as any fixed 168 hour period. Most define Sunday to Saturday. Many do not. Hospitals can elect the 8 and 80 rule under section 7(j), where overtime is calculated over a 14 day period at over 8 in a day or over 80 in the period.

Now swap a shift that sits on a workweek boundary. A Saturday night shift running 10pm to 6am spans two workweeks. Which week do the hours land in? The answer is that they split at the boundary, hour by hour, and each half counts toward a different week's 40. Your swap engine has to allocate a single shift across two overtime buckets. Naive implementations attribute the whole shift to its start date and quietly underpay.

Daylight saving is the second half of this. The spring forward Sunday has a 23 hour day, the fall back Sunday has 25. A shift from 11pm to 7am on fall back night is 9 hours worked, not 8, and it has to be paid as 9. If you store shift times as local wall clock strings, this is invisible and wrong. If you store them as UTC instants only, you lose the employer's legal workday and your daily overtime rule breaks. The correct model is both: store the UTC instant, store the IANA timezone identifier such as America/Los_Angeles, and derive the legal day from the identifier. Never store a fixed offset such as UTC-8, because offsets change twice a year and the IANA database itself changes several times a year when governments move their rules. Pin your tzdata version and treat updates as a deployable event.

Approvals, race conditions and the double booked shift

Swaps are a marketplace. An open shift posted to a pool of 40 people gets claimed by three of them in the same second on three phones with three different network latencies. If you handle this with a read then write, you will double book, and the failure surfaces at 5am when two people show up for one register.

What a competent build does: treat the shift as the concurrency unit and claim it with a conditional update, an UPDATE that includes the current status and version in the WHERE clause and checks the affected row count. In Postgres that is optimistic concurrency with a version column, or a SELECT FOR UPDATE inside the transaction that also runs the eligibility check. The eligibility check must be inside the same transaction as the claim, otherwise you validate against a world that has already changed.

Approval also is not one step. Real chains we have shipped: employee requests, receiving employee accepts, manager approves, and if the swap creates overtime, a district manager approves the cost. That is a state machine with roughly 9 states and timeouts on each. Add auto expiry, because an unanswered swap request 20 minutes before shift start is a no show waiting to happen. Add the eligibility rules that are invisible in a spec and mandatory in reality: certifications (an unlicensed employee cannot take a shift requiring a forklift cert or an RN license), minimum rest between shifts, which in many union contracts and in some jurisdictions is 10 or 11 hours and is separately compensable if violated, minor labor law limits on school nights, and clopening restrictions in the predictive scheduling cities.

Mobile makes it harder. Frontline staff are on the shop floor, in a walk in cooler, or in a parking garage, and they will accept a swap on 1 bar of signal. If you built optimistic offline acceptance, you now need conflict resolution, and last write wins is the wrong policy here, because the loser found out they lost a shift they already planned around. Our position after several of these: do not accept swaps offline. Let the app read the schedule offline, but require a server round trip for the claim, and show a clear pending state. A swap that is not confirmed by the server did not happen.

Push notifications, the part that quietly rots

Swaps are worthless if nobody sees them. This is where builds decay six months after launch.

APNs and FCM do not guarantee delivery, and neither gives you a real read receipt. Tokens churn constantly: on app reinstall, on restore to a new device, and silently when the OS decides to rotate. If you never process the feedback path, your token table fills with dead entries and your delivery rate decays quarter over quarter without a single error in your logs. On APNs you must handle the 410 Unregistered response and delete the token. On FCM you must handle UNREGISTERED and INVALID_ARGUMENT the same way. Android adds Doze mode and vendor level battery optimizers, which on some OEM builds will delay a normal priority message for hours. A shift starting in 90 minutes needs high priority on FCM and interruption level time-sensitive on iOS, and iOS Focus modes will still suppress it unless the user has granted the entitlement.

What a competent build does: never treat push as the system of record. Push is a hint. The truth lives in an in app inbox plus SMS escalation for anything time critical inside a few hours of shift start, with an explicit acknowledgement action. Budget for the SMS. Twilio's published US rate is around $0.0079 per outbound message plus carrier fees, and at 500 employees generating a few swap events each per week it is real money, roughly $40 to $120 a month, plus the A2P 10DLC registration that takes days and that first time builders always forget exists.

Payroll export, where the money actually leaves

The swap changed hours. Now those hours have to reach payroll, and payroll is somebody else's system.

If your client runs ADP Workforce Now, Paychex, Gusto, Paylocity, or Rippling, you are integrating with a partner API that gates access behind an approval process. ADP's partner program is not a signup form, it is a review that takes weeks and involves certification. Nobody plans for that, and it lands squarely on your launch date. The cheap path many products take at first is a file export, and honestly it is often the right call for release one: produce the batch in the format the payroll provider ingests and let a human upload it.

The engineering discipline here is idempotency. Payroll runs get re-sent. A retry that double posts 8 hours is not a bug report, it is a paycheck error and in many states a wage violation with penalties. Every export needs a stable idempotency key derived from the pay period, employee, and a content hash, and the receiving side needs to be able to tell a retry from a genuine correction. Retroactive changes are the other half: a swap approved after the pay period closes has to become a correction entry against a closed period, not a mutation of history. Model your time records as an append only ledger with adjustments, not as rows you update. Every client who skipped this came back for it.

What this actually costs

These are Digital Heroes bands across 2,000+ delivered projects, not industry averages.

Adding shift swapping with overtime rules to an existing product where you already have employees, shifts, and auth: $15,000 to $60,000, typically 4 to 9 weeks. The bottom of that band is a single jurisdiction, FLSA only, manager approves everything, no payroll integration. The top is multi-state with a rules engine and a certified payroll export.

As part of a first release, where scheduling, roles, time tracking and the mobile app are all being built: $50,000 to $130,000 over 10 to 16 weeks.

Full workforce platform with union rules, multi-state, predictive scheduling compliance, payroll integrations, and reporting: $150,000 to $350,000 over 6 to 12 months.

What specifically drives this capability's number up, in order of impact:

Jurisdiction count is the single biggest multiplier. One state is a feature. Five states with California in the set is a compliance product, and California alone typically adds 2 to 3 weeks because of daily overtime, double time, the seventh day rule, and meal and rest premium interactions. Union contracts are worse than statutes, because a CBA can define seniority based shift bidding, guaranteed hours, and premium rules that exist in no public database. We have seen a single CBA add 4 weeks. Retroactive correction handling and the append only ledger adds 1 to 2 weeks but is not optional past about 200 employees. Payroll integration is 2 to 5 weeks of engineering plus an unpredictable partner approval window. Offline mobile behaviour, if you insist on it, adds 3 to 4 weeks and permanent support cost.

What does not drive the number much: the number of screens, the calendar UI, and the notification templates. Buyers spend most of the first meeting on those three.

When you should not build this

If shift swapping is the product, buy it. Deputy, When I Work, Homebase, Sling and 7shifts already have swap plus overtime alerting, they publish list prices in the range of roughly $4 to $8 per user per month, and at 200 employees that is around $1,000 a month against a $60,000 build with maintenance behind it. The break even is years out and they will have shipped compliance updates you now owe yourself, every time a state changes a rule.

Take the off the shelf option if: you have one to a few hundred hourly employees, your scheduling looks like most restaurants or retail, and you have no operational rule that the vendors cannot express. That is the majority of companies asking this question, and telling them otherwise would be dishonest.

Build custom when at least one of these is true. Your scheduling logic is your business, meaning the swap has to respect something no vendor models: skill matrices with certification expiry, patient or client continuity, equipment or route assignment, or a CBA with seniority bidding. You already own the system of record for employees and shifts and bolting a vendor onto it means two sources of truth, which is the worst outcome available and generates exactly the payroll drift described at the top. Or you are the vendor, selling to an industry the incumbents do not serve.

The middle path most people miss: build the swap workflow and the eligibility rules that are yours, and do not build the overtime math. Rules engines exist as services. If your differentiation is not overtime calculation, integrating one is cheaper than owning tzdata updates and 50 state legislatures forever.

How to brief and vet a developer for this

Brief with facts, not features. Give them: every state and city you employ people in, your defined workweek start, whether any site uses 8 and 80, every union contract in force, your payroll provider and its exact version, employee count by site, whether minors are on the schedule, and one real messy week of historical schedule data including a boundary spanning night shift. If a vendor gives you a fixed price before seeing that data, the price is fiction.

Then ask these. The answers separate people who have shipped this from people who have read about it.

"How do you compute overtime for a shift that crosses the workweek boundary?" A shipper says the hours split at the boundary and land in two different weekly buckets. Anyone who says the shift belongs to its start date has not done this.

"How do you store shift times?" You want UTC instant plus IANA timezone identifier, and you want them to bring up daylight saving unprompted. If they say local datetime, or a fixed UTC offset, walk.

"Three people claim the same open shift at once. Walk me through the write." You want a conditional update or row lock with the eligibility check inside the same transaction. If you hear "we check if it's available, then assign it," that is the double booking, described out loud.

"An employee hits 43 hours in California with one 9 hour day. How many overtime hours do they get?" Three, not four, because the daily overtime hour is not counted again toward the weekly 40. If they say four, they will pyramid premiums into every paycheck you run.

"What happens when a swap is approved after the pay period closes?" You want append only records and correction entries. "We'd update the record" means you will be reconstructing payroll by hand.

"Which of our locations have predictive scheduling ordinances, and does an employee initiated swap trigger predictability pay?" If they have not heard of predictive scheduling and you operate in Oregon, Seattle, NYC, SF, Chicago, LA or Philadelphia, they are going to find out on your budget.

"How do you handle a dead push token?" You want 410 on APNs and UNREGISTERED on FCM, plus the statement that push is not the system of record. If push delivery is their notification plan entire, ask what happens when a $22 an hour employee misses a shift because Doze mode held the message for two hours.

"Show me your overtime test suite." This is the real one. Anyone who has shipped this has a golden test file with named scenarios: seventh consecutive day in California, DST fall back night shift, boundary split, minor on a school night. If the tests do not exist, the rules do not either.