An App Developer in San Francisco Who Prices Every Schedule Change

Updated November 2026 · Written and maintained by the Progression Agency strategy team

A store manager on Market Street moves a Thursday closing shift to Saturday on a Tuesday afternoon, two days’ notice, and the scheduling app saves the change without a word about pay. Under San Francisco’s Formula Retail Employee Rights Ordinances, a covered chain owes predictability pay for changes made with less than seven days’ notice, and more when the notice drops under 24 hours. An app developer in San Francisco building scheduling tools for those chains puts the premium on the screen before the manager taps save. Progression is based in New York, builds for San Francisco retailers remotely, and offers on-site sessions on request.

A Thursday shift moved on a Tuesday

The manager is busy and the change is small: Thursday evening to Saturday evening, same hours. The app lets her drag the shift, asks nothing and saves. The worker gets a notification. Nobody sees a number.

OLSE’s presentation on the ordinance says that when a schedule changes with less than seven days’ notice, the employer owes one hour of pay for each shift change. The app knew the time of the change and the date of the shift. It had everything it needed to show that line and showed nothing.

What an app developer in San Francisco builds for covered chains

San Francisco’s Office of Labor Standards Enforcement says the Formula Retail Employee Rights Ordinances apply to formula retail establishments with at least 40 stores worldwide and 20 or more employees in San Francisco, and to their janitorial and security contractors.

Covered employers must offer extra work hours to current qualified part time employees in writing before hiring new employees or using contractors or staffing agencies. New employees get a good faith written estimate of the minimum number of scheduled shifts per month and the days and hours of those shifts. Schedules must be provided two weeks in advance, posted at the workplace or provided electronically if employees can reach the electronic schedule at work.

Each of those is a screen, a timestamp and a record. A scheduling app that carries them does the rule’s work at the moment a manager acts, and a manager’s memory is not asked to.

Why does the app carry the rule and not the manager?

Because the cost of a change depends on two things the manager rarely has in front of her: how many hours before the shift she is acting, and how far the shift moves. The app has both, so it can show the answer before she saves.

What does the manager see first?

The shift she is changing, the time now and the notice that leaves. The hours of pay appear next to the save button, so she sees the cost at the moment of choosing.

• The old shift and the proposed shift side by side.
• The notice in days and hours, counted from now.
• The premium hours and the rule that sets them.
• A reason list that appears only when no premium applies.
• A save button that stays active, since the manager may still choose to make the change.

One schedule change priced at each notice point

The table walks one change through every notice point in OLSE’s page, presentation and final rules. The premium is hours of pay at the employee’s regular hourly rate, and this page prints no dollar figure.

• Posted two weeks ahead: no premium.
• Changed with seven days or more: no premium on OLSE’s page.
• Changed with less than seven days: hours of pay follow.
• Under 24 hours: two or four hours by the size of the change.

The one hour line at seven days

OLSE’s presentation puts the first notice point at seven days: schedule changes with less than seven days’ notice carry one hour of pay for each shift change. The rules then raise the premium as notice shrinks. The app starts the clock the moment a manager opens the shift, not when she saves.

Under 24 hours, by the length of the change

Rule 5.1 prices a change of four hours or less at two hours of pay and a larger change at four. Rule 5.2 prices a moved shift on the distance it moves. The screen needs the size of the change in hours, and a drag on a calendar already knows it.

On call and not called in

An employee required to be on call who is not called in gets 2 to 4 hours of pay, depending on notice and shift length. OLSE’s presentation puts it at two hours for an on call shift of four hours or less and four hours if longer. The app records the on call block, and the release is a change like any other.

What a scheduling app build costs

Price follows the scope: platforms, payroll and HR integrations, how many store roles the schedule covers and how the audit trail is stored. Progression quotes after a written scope, and its method is proprietary and kept for clients. Store fees and hosting come on top.

A scheduling app with a premium calculator, an exemption list and an export usually lands in the mid complexity band once it connects to payroll. Our app development cost guide explains what moves a figure up or down.

Application development in San Francisco around the exemption list

OLSE lists seven cases where an employer does not owe predictability pay or on-call pay: threats to employees or property, failure of public utilities, an act of God or other cause outside the employer’s control, another scheduled employee who could not work and gave less than seven days’ notice, another employee who failed to report or was sent home, required overtime, and an employee who trades shifts or requests a change.

The plain build is a fixed list. At the moment of a change that carries no premium, the manager picks the reason from the list, and the app stores it with the time. An empty reason means the premium shows.

• The list matches the seven cases on OLSE’s page and nothing else.
• Trades and requests start with the employee, in the app, and are logged that way.
• A change with no reason picked shows the premium before it saves.
• Edge cases go to counsel or to OLSE, not to a free text box.

Can a manager type her own reason?

She can add a note, but the exemption comes from the list. A free text reason is hard to audit, and OLSE’s page names specific cases. When none fits, the app shows the premium.

A request button that stays a request

Rule 6.1 says an employer owes predictability pay when it requires an employee to take a shift, and that includes a unilateral schedule change, making the shift a condition of employment, or pressuring or coercing the employee. The rule adds that calling a change a request does not make it one if the pressure would discourage a reasonable employee from declining.

In one rule example, a manager posts a sign-up sheet for a flash sale and employees volunteer: no predictability pay is owed. In another, the manager asks one employee privately and implies she should be a team player: pay is owed. The plain advice for the app is a sign-up screen that every eligible worker sees at once, with a decline button that carries no message to the manager, and no wording that suggests a penalty. No wording guarantees an exemption, so counsel should read the screen.

• Use a sign-up screen that every eligible worker sees at once.
• Make declining as easy as accepting, with no message sent to the manager.
• Keep any wording that hints at a penalty out of the messages.
• Log who was asked, when, and how each person answered.

What does the rule say about scheduling software?

In Rule 6.1’s third example, a company’s software adds a Wednesday shift that the employee sees on Monday morning, and the employer owes one hour of predictability pay. The software here is an actor, so the app should treat its own automatic changes like a manager’s.

Extra hours offered to part time staff first

OLSE’s page says a covered employer must offer extra work hours to current qualified part time employees in writing before hiring new employees or using contractors or staffing agencies. An offer screen with a timestamp is the record.

The same page requires equal treatment of part time employees on starting hourly wage, access to paid and unpaid time off and eligibility for promotions, compared with full time employees at the same level. Those rules sit in pay and HR systems, so the scheduling app should not make decisions about them.

• Send the offer to every qualified part time employee at once.
• Show who received it, when, and who replied.
• Keep pay and promotion rules out of the scheduling logic.
• Let the hiring screen check that an offer was sent first.

Mobile application development in San Francisco for contractors too

OLSE’s page says janitorial and security contractors of covered chains follow most of the same provisions, and that the chains must notify their contractors of the requirements. A chain that uses contractors needs the app to carry two employers on one schedule.

The plain build keeps the two employers’ schedules, premiums and records separate while letting the chain see that its contractors’ schedules went out on time. Our HR software development page covers payroll and HR connections.

Three years of schedules on file

OLSE’s August 2015 presentation says employers keep work schedules and payroll records for three years. The app keeps every schedule version and every change with its time, so an export by worker and week rebuilds what a past schedule looked like. Confirm the period with OLSE or counsel before setting retention.

Questions for payroll and counsel before launch

A scheduling app touches pay, so two reviews belong before it goes live. Payroll checks that the hours the app shows are the hours that reach a paycheck. Counsel reads the screens and the wording.

• Does the regular hourly rate come from payroll, not from the schedule?
• Does the app count a change from the time it is made, not the time it is saved?
• Does counsel agree with the list of reasons the manager can pick?
• Does the export match what OLSE would ask to see?
• Is the retention period confirmed with OLSE or counsel?

Who calculates the regular hourly rate?

Payroll does. Rule 4.1 sets how it is figured from prior calendar year earnings and hours, and the scheduling app should read the result and not recalculate it.

Does the app need to know the store’s headcount?

Coverage depends on the chain’s counts, so the chain sets it at the account level, with counsel’s help. The app applies the rules to stores marked as covered.

Who to ask when the app and the rule disagree

The Office of Labor Standards Enforcement answers coverage and pay questions at 415-554-6461 and frero@sfgov.org. Rule text sits in the final rules OLSE issued on January 29, 2016, effective March 1, 2016, with citations updated for the Labor and Employment Code, operative January 4, 2024. The ordinances are Articles 41 and 42 of that code, which the Board of Supervisors passed on November 25, 2014.

• Coverage questions go to OLSE or counsel.
• Pay questions go to payroll and then to OLSE.
• Wording questions go to counsel.
• Build questions go to the app team.

For retail systems around the schedule, see our retail software development page. For San Francisco software outside scheduling, our software company in San Francisco page covers a different question.

Frequently asked questions