Cost to Build a Workforce Scheduling App Like Deputy: What Operators Actually Pay

A restaurant group running 22 venues across New South Wales, Victoria, and Queensland pays Deputy $4.90 per user per month on the Premium plan. With 840 staff on roster at any given time, that is $49,392 per year -- before adding the award interpretation module required to correctly apply the Hospitality Industry (General) Award, which charges additional enterprise pricing on top. The group's rostering coordinator manually cross-checks penalty rate outputs every pay cycle because the award configuration "isn't quite right" for their split-site casual arrangements. Back-payment exposure from a single Fair Work Ombudsman investigation runs to tens of thousands of dollars.

This article is for operators in that position: hospitality groups, retail franchise chains, healthcare networks, and multi-jurisdiction employers who have grown beyond the use case Deputy was built for -- the small business paying $3.50/user/month with 35 staff and one award. If you are weighing a custom scheduling platform build against continuing to pay per-user SaaS fees to Deputy or one of its competitors, what follows covers real build costs, what multi-jurisdiction compliance adds to the scope, and when the math tips clearly toward ownership.

How much does it cost to build a workforce scheduling platform like Deputy?

Building a workforce scheduling and time-attendance platform costs $60,000 to $180,000 depending on scope. A V1 with roster building, mobile time clock, and leave management takes 12--16 weeks. A full platform with an award interpreter, branded employee app, and multi-jurisdiction payroll compliance takes 24--32 weeks.

What moves the cost range: whether you need the award interpreter built from scratch or can start with an integration to Tanda's engine, whether the employee mobile app is cross-platform (saves $25,000--$40,000 versus native iOS and Android separately), how many payroll systems you must integrate with at launch, and how many jurisdictions' compliance rules must be enforced in the scheduling engine itself. Cross-platform mobile is the right call for a time-clock and shift-notification app -- the performance requirements are modest and the cost difference is significant.

According to the Fair Work Ombudsman's 2022-23 Annual Report, the FWO recovered more than $532 million in back-payments during that financial year -- the majority from underpayments in hospitality, retail, and fast food. Many of those cases involved scheduling software that calculated hours correctly but applied the wrong penalty rates. The liability sits with the employer, not the software vendor.

How Deputy makes money -- and what you capture when you own the platform

Deputy is a per-seat SaaS business. Every employee on your roster is a billable unit. At $3.50/user/month (Scheduling), $4.90/user/month (Premium), or $5.90+/user/month (Enterprise), the fee grows with every new hire. There is no ceiling.

At 200 staff, Deputy costs $8,400--$14,160/year. At 500 staff, that is $21,000--$35,400. At 1,000 staff, $42,000--$70,800. The award interpretation capability that AU hospitality operators genuinely need to reduce back-payment risk sits behind the Enterprise tier -- the one with pricing that requires a sales call.

Deputy also earns from marketplace integrations. Payroll connectors, HR systems, and POS integrations each carry setup or per-connection fees depending on the integration partner. When you build your own platform, you own those integrations directly.

When you own the scheduling platform, the fee structure changes entirely. The platform has a build cost (one-time) and a maintenance cost (ongoing, typically $8,000--$20,000/year for hosting, security patches, and annual award rate updates). At 500+ staff, break-even on a $95,000--$130,000 build typically comes within 2--3 years. Past that point, every additional hire adds zero to the platform cost.

The other thing you capture when you own the platform: your data. Roster history, attendance records, leave balances, and award interpretation outputs are in your system. When an employee disputes a pay calculation, the full audit trail is yours to produce -- not an export request to a third-party SaaS vendor.

Who builds a custom scheduling platform instead of using Deputy?

Four types of operators regularly find that Deputy was built for someone smaller or simpler.

AU hospitality chains where award interpretation accuracy is liability-critical

An 18-venue restaurant group operating under the Hospitality Industry (General) Award needs penalty rate calculations that correctly handle: overtime after 38 ordinary hours per week, double-time on public holidays, evening penalty rates after 9pm, split-shift allowances, and minimum shift engagements of 2 hours. The specific award conditions interlock in ways that are genuinely complex for multi-day casual arrangements. A scheduling platform that applies these rules correctly protects the operator from Fair Work Ombudsman investigations. One that approximates them -- relying on manager overrides to catch edge cases -- is an underpayment waiting to be audited.

The Australian Bureau of Statistics estimates 2.97 million people work in accommodation, food services, and retail trade in Australia. The operators at scale in those industries are exactly the ones who cannot afford to get penalty rates wrong.

UK retail franchises operating near Working Time Directive limits

A franchise chain running 60 stores across the UK employs a mix of full-time and part-time workers. Some have signed WTR opt-out agreements; others haven't. The scheduling platform must track 17-week rolling averages for every worker, flag shifts that would push a non-opted-out worker past 48 hours, and enforce mandatory rest intervals. The operations manager should not be calculating rolling averages manually -- but they are, because Deputy's WTR enforcement in UK accounts depends on configuration that most franchise operators do not set up correctly.

Healthcare facility networks where credentialing gates shift assignments

A private hospital network running four facilities needs scheduling software that blocks a nurse from being assigned a shift in a clinical unit if their registration with AHPRA (Australia) or the NMC (UK) has lapsed. It also needs to match the right skill mix per shift (a ratio of registered nurses to enrolled nurses to patient care assistants), track mandatory training compliance, and handle on-call scheduling separately from rostered shifts. Deputy handles standard shift scheduling well. It does not natively handle credentialing gates, skill-mix enforcement, or the dual roster model (on-call versus rostered) that clinical operations require.

Multi-jurisdiction global operators where Deputy's compliance depth is uneven

A global workforce services company with operations in AU, UK, and the US needs one platform that applies Fair Work Act award rules in Sydney, Working Time Directive limits in Manchester, and FLSA overtime calculations in Chicago. Deputy has functionality in all three markets -- but the depth of compliance enforcement varies, and the platform was not designed to enforce jurisdiction-specific rules from a single unified admin console. For a global operator managing compliance across three different legal frameworks in one workforce, the custom build is the only way to get consistency.

What features does a workforce scheduling MVP need?

How the build timeline breaks down week by week

The biggest mistake operators make when scoping a scheduling platform build is treating the award interpreter as a module to add later. It is not. The award interpreter determines the data model for shifts, timesheets, and pay calculations. Building the roster first and adding the interpreter after forces a significant refactor. Design it in week one.

Weeks 1--2: Data architecture -- the location-to-team-to-employee hierarchy, shift structure, timesheet schema, and pay period model. Award interpreter design: which awards to support, which clauses to enforce, how interpretation outputs feed into the payroll export. GDPR data flow mapping for employee personal data.

Weeks 3--5: Roster builder -- drag-and-drop shift creation, shift templates, recurring patterns, location and role assignment, open shift publishing. Manager and admin user roles with location-scoped access.

Weeks 6--8: Time clock module -- mobile punch-in/out with GPS verification and geofence configuration per location. Missed punch alerts and correction workflow. Attendance view in manager dashboard.

Weeks 9--11: Leave management -- employee leave request submission, manager approval workflow, leave balance ledger, leave type configuration (annual, personal, sick, public holiday, long service). Roster visibility of approved leave.

Weeks 12--14: Shift acknowledgment and notification engine. Basic payroll export (hours worked, leave, overtime flag). Manager reporting dashboard. Coverage gap alerts.

Weeks 15--16 (V1 launch): QA across the full roster-to-timesheet-to-export flow. Payroll export validation against a sample pay run. Manager training materials. UAT with the operator's rostering team.

Weeks 17--20 (V2): Award interpretation engine. Fair Work Act clause implementation for the agreed award set (Hospitality, Retail, Restaurant, Clerks). Integration with timesheet output. Pay period calculation output mapped to payroll export format.

Weeks 21--26 (V2): Branded employee app (iOS + Android, cross-platform). Shift schedule view, leave balance, shift swap request flow, push notifications. STP Phase 2 payroll export structure. Direct Xero/MYOB/KeyPay integration via their respective APIs.

Weeks 27--32 (V3): Multi-jurisdiction compliance engine. FLSA overtime logic. WTR rolling-average tracking for UK employees. GDPR consent and retention workflows. Biometric terminal integration if in scope. Workforce analytics dashboard.

What compliance requirements does a scheduling platform need to get right?

Fair Work Act 2009 (AU) -- the one that generates back-payment liability

The Fair Work Commission updates modern award rates every July 1. The 2023-24 annual wage review applied a 5.75% increase to award minimum rates. A scheduling platform that hardcodes rate tables instead of consuming an updateable award rate source is out of date by July 2 of every year -- and that gap between what the software calculates and what the award requires is underpayment.

The Fair Work Ombudsman's 2022-23 Annual Report identified hospitality and retail as the highest-risk sectors for underpayment compliance. The FWO has civil penalty powers: up to $16,500 per contravention for an individual and $82,500 per contravention for a corporation. In systemic underpayment cases, those penalties compound across every affected employee and every affected pay period. A scheduling platform that gets award interpretation wrong at scale is not a technology problem -- it is a legal liability.

"Employers need to ensure their rostering and payroll software is configured to apply the correct modern award conditions for each employee classification. A system that cannot correctly identify when a split-shift allowance applies, or when a casual conversion trigger has been reached, creates underpayment risk regardless of the software vendor's general reputation."

-- Fair Work Ombudsman Guidance Note, Hospitality Industry (General) Award 2020 compliance, published 2023

The award interpretation must handle: ordinary hours (38 per week for full-time, proportionate for part-time), overtime rates (150% for the first two hours, 200% after), weekend penalty rates (150% Saturday, 175% Sunday under the Hospitality Award), public holiday rates (250%), evening penalties (115% after 6pm under some awards), and minimum shift engagement (typically 2 hours for casuals). Split shifts that cross midnight require the ability to split a single shift's hours into two calendar-day calculation windows -- a data model requirement that surprises teams who didn't model it upfront.

Working Time Regulations 1998 (UK) -- rolling averages and rest mandates

The Working Time Regulations 1998 (SI 1998/1833) impose obligations that are more complex to enforce than they first appear. The 48-hour weekly limit is measured as an average over a 17-week reference period -- not a hard cap on any single week. An employee who works 55 hours in one week is not automatically in breach; whether they are depends on their hours across the preceding 16 weeks.

A scheduling platform for UK employers must: calculate rolling 17-week averages per employee on every roster publication, flag any proposed shift that would push a non-opted-out worker above the average limit, enforce 11 consecutive hours of rest between shifts, require 20 minutes of rest for any shift exceeding 6 hours, and limit night workers to an average of 8 hours per 24-hour period. The CIPD Good Work Index 2024 found that 34% of UK workers report excessive workload as a primary stressor -- a figure that rises in hospitality and retail, exactly where scheduling pressure is highest.

Employers must maintain records adequate to demonstrate WTR compliance to the Health and Safety Executive. A scheduling platform that does not produce WTR audit records is asking the HR team to maintain them manually.

FLSA (US) -- exempt vs non-exempt and blended overtime

The Fair Labor Standards Act (29 U.S.C. § 207) requires overtime at 1.5x the regular rate for non-exempt employees working more than 40 hours in a workweek. The complexity for scheduling platforms is the "regular rate of pay" calculation when a worker has multiple pay rates in a week (shift differentials, tips, or different hourly rates for different job roles). A tipped employee who also earned non-tipped hours in the same workweek has a different regular rate of pay than one who only worked tipped hours.

According to the BLS Occupational Outlook Handbook 2024-25, approximately 3.9 million food service supervisors and managers are employed in the US -- the majority of whom are non-exempt and entitled to FLSA overtime protections. A scheduling platform that exports hours to payroll without correctly flagging overtime eligibility and the correct regular rate for blended-rate workers creates underpayment exposure.

GDPR and STP Phase 2

Employee scheduling data is personal data under GDPR. Name, work location, shift patterns, and biometric time data (where collected) are all in scope. A platform handling EU or UK employee data must have documented lawful basis for processing (typically legitimate interests or contract performance), data retention policies applied automatically (not just documented), a right-to-erasure workflow for employees who leave, and data processing agreements with any payroll integration that receives the export.

STP Phase 2 (AU) requires payroll exports to include income type disaggregation (salary and wages, closely held payee payments, etc.) and more detailed allowance breakdowns than STP Phase 1. If the platform is generating payroll data that feeds directly into an STP-compliant payroll system, the export schema must match STP Phase 2 requirements -- an ATO data structure standard, not a vendor format.

What technical challenges do scheduling platforms actually run into?

Award interpreter maintenance is a recurring cost, not a one-time build

The Fair Work Commission updates modern award conditions every July 1 following the annual wage review. It also amends specific award clauses throughout the year -- the Hospitality Award had clause changes in both 2022 and 2023 related to casual conversion rights. A scheduling platform with a built-in award interpreter requires a structured process for consuming these changes and applying them to the interpretation engine before they take effect.

Teams that build the interpreter as a hardcoded rules engine discover this problem at the first annual update. The correct architecture represents award rules as data (rate tables, clause conditions, effective-date ranges) rather than code. An update then becomes a data load, not a code change. Build it right the first time and the annual update takes 2--3 days of work. Build it wrong and each update is a 3--4 week engineering engagement.

Concurrent shift change conflict resolution creates payroll errors

When a manager modifies a shift -- say, extending the end time from 10pm to 11pm -- while the employee has already clocked out at 10pm and their timesheet is in the submitted state, the system has a conflict. The manager's edit changes the scheduled end; the employee's timesheet records the actual end. Most scheduling platforms resolve this by keeping both records and requiring a manager to reconcile the discrepancy manually. That reconciliation either happens in the software (creating an audit trail) or in a spreadsheet (no trail).

The harder case is when two managers in different locations are simultaneously editing the same employee's shift -- which happens in hospitality groups where an employee works at multiple venues in the same week and different area managers have scheduling authority over different locations. A naive last-write-wins approach loses one manager's edit with no notification. The correct model is optimistic locking: each edit carries a version number; a conflicting edit is rejected with a notification, not silently overwritten. Design this conflict model before building the shift-editing UI, not after discovering the problem during payroll reconciliation.

Biometric terminal integration edge cases

Time-capture hardware (fingerprint readers, facial recognition terminals) creates integration challenges that pure-software teams consistently underestimate. The terminal must be networked reliably to sync punch data to the platform in real time -- or store punches locally during network outages and sync on reconnect. Missed syncs during outages create gaps in the timesheet that must be flagged for manager review rather than silently creating a zero-punch record.

Template drift is the other failure mode. A biometric terminal stores enrolled templates for each employee. When an employee's fingerprint changes (injury, manual labor that roughens skin), the terminal starts rejecting their punches. The platform must have a re-enrollment workflow and a fallback (PIN or supervisor punch-in) that does not break the attendance record.

Payroll export reconciliation failures

Payroll integrations fail at the boundary between scheduling logic and payroll system expectations. Xero expects gross pay calculations; KeyPay expects raw hours and pays with its own award interpreter; MYOB has specific field mappings for leave types that don't match the natural language names operators use internally. A payroll export that passes validation but creates wrong entries in the payroll system because of field mapping assumptions is worse than one that fails visibly -- it underpays silently.

The correct approach is an integration test suite that runs against a sample pay period after every change to the export schema, flags any deviation from expected payroll output, and requires sign-off before the change goes to production. Most builds skip this and discover mapping errors after the first live pay run.

Build vs. Deputy: when does the math tip?

Keep using Deputy when: fewer than 200 staff on roster. One award, one country, standard hours with no unusual penalty rate arrangements. Your annual Deputy bill is under $15,000. Deputy's employee app covers your staff's experience requirements. You don't have internal capacity (or budget) to maintain a custom platform.

Use Tanda when: you need AU award interpretation depth without a custom build. Tanda's award engine is the strongest in the AU market and covers more awards than Deputy's configuration. For operators who need AU compliance but don't want to build, Tanda is the right SaaS choice.

Use WhenIWork or Humanity when: US-only operations with straightforward scheduling (no multi-rate overtime complexity). Both are stronger than Deputy in the US mid-market.

Build your own when: three or more of these apply.

You have 500+ staff and your Deputy bill exceeds $35,000/year. A $95,000 V2 build pays back in under 3 years. At 1,000 staff paying $5.90/user/month, payback is under 18 months.

Your AU operations require award interpretation accuracy that Deputy's configuration cannot deliver for your specific award structure -- particularly if you have casuals under the Hospitality Award with split-shift arrangements or irregular hours patterns.

You need scheduling logic integrated directly with your payroll system without a middleware export step. Every manual CSV export or third-party connector is a reconciliation failure waiting to happen.

You operate across AU + UK + US and need jurisdiction-specific compliance rules (Fair Work, WTR, FLSA) enforced from a single platform with a single admin view.

You need employee data and roster history in your systems -- not in Deputy's database -- for legal discovery, Fair Work audit response, or operational analytics that Deputy's reporting doesn't support.

How does Deputy compare to its main competitors?

Deputy competes for hourly workforce operators against Tanda (AU-strong), WhenIWork (US-strong), Humanity/TCP (enterprise US), and Rippling's workforce module (HR-first platform with scheduling add-on).

Deputy's strengths: the broadest geographic footprint (AU, UK, US, CA in one product), a polished employee mobile app, and the strongest brand recognition in the AU mid-market. Its scheduling and time-clock core is reliable.

Deputy's weaknesses at scale: the award interpretation module sits behind Enterprise pricing and requires significant configuration by the operator (or a Deputy implementation partner) to apply correctly to non-standard arrangements. The payroll integrations work but require a middleware export step that creates reconciliation work. Per-user pricing has no ceiling -- a hospitality group that doubles headcount doubles its Deputy bill with no corresponding improvement in capability.

Tanda is the AU market's strongest award interpreter. Its Fair Work compliance depth exceeds Deputy's at every tier. The tradeoff is a less polished employee experience and weaker international coverage. AU operators who need the award engine above all else often choose Tanda over Deputy.

WhenIWork and Humanity are US-centric. They handle FLSA overtime correctly and are better choices than Deputy for US-only operators. Neither has meaningful Fair Work or WTR depth.

Rippling's workforce module is not a scheduling-first product. It is an HR platform with scheduling added. For operators whose primary pain is scheduling and time capture (not HR workflow), Rippling's scheduling is too shallow and its pricing too high for mid-market hospitality groups.

A custom build wins on three things none of the above can match: award interpretation built specifically for your awards and your classifications, payroll integration with no export step or middleware, and total data ownership for compliance audit response.

Where scheduling platform builds go wrong

The failure mode that costs the most to fix is building the roster data model before modeling the award interpreter. A shift in a scheduling system seems simple: start time, end time, employee, location, role. But an award interpreter that correctly applies the Hospitality Industry (General) Award needs to know: was the shift on a public holiday? Did any part of it fall after 9pm (evening penalty)? Was it a split shift (two separate periods with a break of more than one hour, triggering the split-shift allowance)? Did the shift cross midnight -- which means parts of it fall on different calendar days with potentially different penalty rates?

A data model that stores a shift as a single start_datetime and end_datetime cannot support split-shift detection without additional columns. It cannot support midnight-crossing penalty calculation without splitting the shift into day-segments at build time. Teams that build the roster without these requirements in the schema spend 6--8 weeks refactoring the data model after they start building the award interpreter -- a refactor that also requires migrating any existing timesheet data to the new schema.

Design the award interpreter requirements first. Then build the shift schema to support them. Then build the roster UI on top of the schema. That order takes the same total time as getting it wrong and fixing it -- but it doesn't require a mid-build refactor that stalls the team and pushes the launch date.

How RaftLabs fits

We have built workforce scheduling and HR automation platforms for operators in hospitality, retail, and healthcare. The work is familiar: the data hierarchy from enterprise group to legal entity to location to team to employee, the award interpretation problem, the payroll integration plumbing, and the compliance obligations across AU/UK/US are patterns we have worked through before across similar builds.

For a scheduling platform build, we work in fixed-price cycles. V1 scope is defined in a two-week scoping engagement before writing code. We model the award requirements, design the shift schema to support them, identify the payroll integration target, and map the jurisdiction-specific compliance rules your operation needs to enforce. The scoping output is a build specification with a fixed price and timeline -- the number in the proposal is what you pay.

If you are paying more than $35,000/year to Deputy and operating under the Fair Work Act, the Working Time Directive, or both, a scoping call is the right next step. Tell us your headcount, your awards (AU), your jurisdictions, and your payroll system, and we will give you a realistic build cost and timeline within two business days.