Back to work

Restaurant operations · Paid contract

Gyu-Kaku Portal

An internal operations platform for Gyu-Kaku Vancouver that replaces fragmented spreadsheet workflows with structured staff administration and constraint-based schedule generation.

Role
Solo Full-stack Developer
Team
1 developer · 5 operational stakeholders
Period
May 2026 – July 2026
Status
Pilot in active use · Broader rollout planned for September 2026

Measured outcomes

< 10 sec
Initial schedule draft

Generates the initial combined FOH and BOH schedule draft.

6–10 hrs → ≤ 1 hr
Weekly scheduling workload

Includes approximately 20–30 minutes of manager review and manual adjustment after generation.

Reported by the Gyu-Kaku Vancouver management team.

90%+
Reduction in availability-related human error

Reported by the Gyu-Kaku Vancouver management team.

Gyu-Kaku Portal manager dashboard showing staff, availability, vacation, performance-level, and scheduling operations.
Operations overviewThe manager dashboard brings staff administration, availability, vacation, performance levels, and schedule automation into one operational workspace.

01

Context

Staff records, availability, vacation requests, schedules, and performance information were distributed across spreadsheets, email, and direct messages.

Managers manually copied and reconciled those sources while preparing separate FOH and BOH schedules.

Formatting shifts, misplaced rows, similar employee names, and separately communicated time restrictions could produce incorrect availability records.

Vacation requests were submitted by email and tracked separately, while blackout periods had to be announced and checked manually.

Staff had limited visibility into request status, time-specific availability, and changes to their role-based performance levels.

02

Users

  • Gyu-Kaku Vancouver staff submitting availability and time-off requests, viewing published schedules, and following their role-based performance history.
  • Managers and supervisors reviewing requests, maintaining staff records, configuring operational requirements, and preparing schedules.
  • The pilot currently includes approximately 15 users, with about 30 expected during the initial rollout and capacity for future growth.

03

My responsibilities

  1. 01Product proposal and scope definition
  2. 02Stakeholder interviews and requirements gathering
  3. 03Information architecture and UI/UX design
  4. 04Frontend and backend development
  5. 05Database and authorization design
  6. 06Constraint-based scheduling engine
  7. 07Infrastructure and deployment
  8. 08Pilot testing and maintenance
  9. 09Documentation and staff training

04

Constraints

  • Availability, approved vacation, roles, and time-specific working restrictions must be respected.
  • A staff member cannot be assigned to overlapping shifts or receive an unauthorized double shift.
  • Operational labels such as Closing must remain visible to staff while the solver uses estimated end times for conflict and workload calculations.
  • Coverage, weekly-hour balance, fairness, and individual preferences should be optimized without bypassing eligibility rules.
  • Managers must be able to adjust generation settings and edit the resulting draft before publication.
  • A generated result must not overwrite a newer manual draft.
  • Published schedules must preserve what staff saw at each publication point.
  • The product and all public claims apply only to the authorized Gyu-Kaku Vancouver operation.

05

Implemented features

  • Staff and manager authentication
  • Role-based authorization
  • Staff profile and employment record management
  • Availability submission with 15-minute start-time restrictions
  • Missing-availability tracking and manager review
  • Vacation requests, approval history, and blackout periods
  • Automatic exclusion of approved vacations from scheduling
  • Weekly FOH and BOH schedule management
  • Google OR-Tools CP-SAT draft generation
  • Configurable staffing targets and optional operational shifts
  • Manual schedule editing and reassignment
  • Scheduling conflict validation and override review
  • Staffing-shortage and solver diagnostics
  • Version-protected draft persistence
  • Schedule publication and immutable published snapshots
  • Staff-facing published schedule
  • Role-based performance ratings, history, and visual trends
  • Responsive staff and manager interfaces
Weekly availability form with separate Lunch and Dinner selections and time-specific availability controls.
Structured staff inputStaff can submit Lunch and Dinner availability with specific start times, removing the need to communicate exceptions through separate messages.
Generated FOH schedule draft displaying staff availability, assigned shifts, unavailable periods, and vacation states across the week.
Editable schedule draftThe generated draft combines availability and assigned shifts in one weekly view. Managers can review the result before saving or publishing it.
Schedule-generation result showing assignment count, unfilled targets, generation time, optimization score, and staffing shortages.
Actionable diagnosticsA valid partial result is preserved while unfilled staffing targets are reported by date, service, and role. Managers can see where operational review is required instead of receiving only a generic solver failure.
Staff performance-level screen showing role-specific metrics, evaluation notes, and a historical level chart.
Visible performance historyStaff can review the metrics, notes, and historical changes behind their role-based performance level rather than seeing only the latest result.

V01

From fragmented coordination to shared operational data

The portal brings staff inputs, manager decisions, and published schedules into one traceable workflow.

Before

  1. 01Staff submit availability through shared spreadsheets.
  2. 02Time-specific restrictions are sent separately by message.
  3. 03Vacation requests and blackout periods are tracked through email and announcements.
  4. 04Managers manually reconcile the information before building FOH and BOH schedules.

With the portal

  1. 01Staff submit structured availability and start-time restrictions.
  2. 02Vacation requests, approvals, and blackout periods share one source of truth.
  3. 03Validated operational data becomes input for schedule generation.
  4. 04Managers review and edit the draft before publishing a preserved staff-facing schedule.
The product reduces manual transcription without removing manager review or operational judgment.

V02

How a schedule becomes an editable draft

The solver is one part of a broader workflow that validates inputs, protects newer work, and reports incomplete coverage.

V03

Hard rules and weighted objectives

The model distinguishes assignments that must never occur from operational goals that should be balanced.

Hard constraints

  1. 01Respect submitted availability and start-time restrictions.
  2. 02Exclude approved vacation dates.
  3. 03Assign only staff eligible for the required role.
  4. 04Prevent overlapping or unauthorized double shifts.
  5. 05Respect individual hard-hour limits.

Soft objectives

  1. 01Improve coverage across each role and service.
  2. 02Balance weekly hours and assignment fairness.
  3. 03Account for role and service preferences.
  4. 04Support busier days and optional operational coverage.
  5. 05Return the strongest valid partial draft when full coverage is impossible.
A valid partial schedule with explicit shortages is safer than a complete-looking schedule that assigns unavailable or ineligible staff.

06

Technical decisions

01

Use a proven constraint solver

Problem
Scheduling required availability, vacation, role eligibility, overlapping shifts, weekly hours, coverage, and staff preferences to be evaluated together.
Options considered
  • — Keep schedule creation entirely manual
  • — Add automated draft generation with an established constraint solver
Decision
Use Google OR-Tools CP-SAT to generate an initial schedule draft.
Why
Rather than building and validating a custom optimization engine, I used a mature, freely available solver and focused on accurately modeling the restaurant’s operational rules.
Trade-offs
  • — The quality of the output depends on accurate operational data and carefully modeled constraints.
  • — Constraint and objective changes require representative schedule scenarios and regression testing.
  • — Solver output still requires clear diagnostics and manager review.

02

Separate hard constraints from operational objectives

Problem
Treating every staffing preference as mandatory could make an entire week infeasible, while treating eligibility rules as preferences could create invalid assignments.
Options considered
  • — Require every staffing and preference rule to be satisfied
  • — Use penalties for all rules and allow any rule to be violated
  • — Separate non-negotiable eligibility rules from weighted operational objectives
Decision
Model availability, vacation, role eligibility, overlap, and individual hard-hour limits as hard constraints, while treating coverage, fairness, weekly-hour balance, and preferences as weighted objectives.
Why
The solver can produce the best valid partial draft when full coverage is impossible without assigning someone to a shift they cannot work.
Trade-offs
  • — A successful generation does not necessarily mean that every position is filled.
  • — Managers must review shortage diagnostics before publishing.
  • — Soft-rule weights can produce valid but operationally unsatisfying results if they are configured poorly.

03

Keep automatic output editable

Problem
Restaurant schedules are affected by situational judgment that may not be fully represented in an optimization model.
Options considered
  • — Publish the generated schedule automatically
  • — Return multiple schedules for managers to compare
  • — Insert one generated result into the existing editable draft workflow
Decision
Return an editable draft that passes the same validation as manually created assignments.
Why
Managers retain final control while the solver removes most of the repetitive assignment work.
Trade-offs
  • — The workflow is not completely automatic.
  • — Manual edits still require conflict validation and explicit publication state.
  • — The product must clearly distinguish generated assignments, saved drafts, and published schedules.

04

Report partial coverage instead of discarding valid work

Problem
Real staffing shortages can make full coverage impossible even when many valid assignments are available.
Options considered
  • — Fail the complete generation when one position cannot be filled
  • — Relax employee eligibility rules
  • — Save the valid portion and report the uncovered requirements
Decision
Generate the best valid partial draft and return diagnostics describing the affected date, service, role, target, assigned count, and shortage.
Why
Managers can continue from useful work without the system assigning unavailable or ineligible staff.
Trade-offs
  • — Managers must understand that a generated draft may still be incomplete.
  • — The interface must distinguish staffing shortages from invalid policies and solver failures.
  • — Candidate exclusion explanations can be improved further.

05

Separate displayed tasks from solver time estimates

Problem
Restaurant schedules use operational labels such as Closing, Break Cover, Helper, and Prep, but overlap and weekly workload calculations require a concrete time range.
Options considered
  • — Replace every operational label with a fixed displayed end time
  • — Exclude task-based shifts from overlap and workload calculations
  • — Preserve the displayed task while using a solver-only estimated end time
Decision
Store the operational label for the schedule and use role- and day-specific estimated end times only inside solver calculations.
Why
The schedule remains familiar to staff while the optimization model can detect conflicts, evaluate double shifts, and estimate weekly workload.
Trade-offs
  • — Estimated times must not be presented as confirmed working hours.
  • — Role- and day-specific estimates require policy maintenance.
  • — Workload calculations remain estimates for task-based shifts.

06

Protect manual work with optimistic concurrency

Problem
A manager can edit an existing draft while schedule generation is running, allowing a late solver result to overwrite newer manual work.
Options considered
  • — Always replace the current draft with the generated result
  • — Prevent all editing while generation runs
  • — Validate the draft version again before saving the result
Decision
Send the expected draft lock version with generation and reject the result if the draft changes before persistence.
Why
Managers can continue working without risking silent data loss from a stale generation result.
Trade-offs
  • — A rejected result may need to be generated again.
  • — The client must present version conflicts clearly.
  • — Draft mutations must consistently participate in version checks.

07

Connect operational workflows through one data source

Problem
Separate spreadsheets, email, and messages caused staff information, availability, vacation, schedules, and performance history to drift out of sync.
Options considered
  • — Improve the existing spreadsheet templates
  • — Create separate tools for each workflow
  • — Connect the workflows through one application and relational database
Decision
Use PostgreSQL as the shared data source for staff, requests, availability, schedules, publication history, and role-based performance records.
Why
Approved information can affect downstream workflows directly without being copied and checked again.
Trade-offs
  • — The application requires authentication, migrations, backups, deployment, and ongoing operational ownership.
  • — Changes to connected workflows can affect several domains and require broader validation.
  • — The private operational system requires careful demo-data and disclosure controls.

07

Outcome

  1. 01The complete agreed feature scope was implemented before the pilot and is currently in active use.
  2. 02The initial combined FOH and BOH schedule draft is generated in under ten seconds.
  3. 03Manager scheduling work decreased from approximately six to ten hours per week to no more than one hour, including review and adjustment.
  4. 04Availability-related human error decreased by approximately 90%, according to the Gyu-Kaku Vancouver management team.
  5. 05Staff can submit time-specific availability without sending a separate message to a manager.
  6. 06Vacation requests, blackout periods, approval status, and scheduling eligibility now share one workflow.
  7. 07Staff feedback indicated that role-based performance changes and their contributing metrics became easier to follow through the visual history.
  8. 08No major new workflow problem has been identified during the pilot so far.
  9. 09The broader Gyu-Kaku Vancouver rollout is planned for September 2026.

08

Reflection

The most important lesson was that optimization quality depends more on domain modeling than on the solver itself. I chose OR-Tools instead of building a custom scheduling algorithm so I could focus on translating real restaurant operations into reliable constraints, validation, and manager workflows.

Building the manual draft and publication lifecycle before automation proved valuable. The solver does not control the operation; it creates an editable starting point that managers can review and adjust.

I am particularly satisfied that the product serves both sides of the workplace. Managers gain a faster scheduling workflow, while staff can submit precise availability, manage vacation requests, view published schedules, and follow changes in their role-based performance levels.

If I rebuilt the scheduling architecture, I would persist each generation attempt with its policy version, daily inputs, solver status, objective breakdown, diagnostics, execution time, and resulting draft version.

I would also strengthen manager-facing explainability so the system could show not only where staffing is short, but why individual candidates were excluded.

The current synchronous execution remains appropriate because generation completes in under ten seconds. I would introduce background jobs only if scheduling volume or model complexity made synchronous requests unreliable.

09

Technology

  • React
  • React Router
  • TypeScript
  • Tailwind CSS
  • FastAPI
  • Python
  • PostgreSQL
  • SQLAlchemy
  • Alembic
  • Google OR-Tools
  • Docker
  • Nginx