Loading…
Delivered, stakeholder handover in progress
Basic Needs Scheduling
An AI-assisted scheduling system for the Hungry Wildcat Food Pantry, built to replace a 15-to-20-hour manual process, and to never pretend a schedule is finished when it isn't.
Organization
Chico State Basic Needs, Hungry Wildcat Food Pantry
Role
Product Owner and AI-Assisted Developer
Period
July 2026 – Present
Status
Delivered, stakeholder handover in progress
Version 1.2 delivered and already demonstrated live to the pantry coordinator. Four of five requests from that demo have shipped; formal handover to Basic Needs staff is in progress. 349 automated tests passing.
The problem
The pantry coordinator spent an estimated 15 to 20 hours building each semester's student-employee schedule by hand in Excel, then edited it continuously as classes changed and students called out. She had already tried automating it with a general-purpose AI chatbot. It failed: it placed lunch breaks at the start of shifts instead of the middle, produced fragmented one-hour blocks, and invented schedules that weren't real when the actual data couldn't support one. She abandoned it and went back to doing it by hand.
The goal
Build a system that encodes the pantry's actual scheduling rules as tested, deterministic logic, does the arithmetic automatically, explains every recommendation, and, the part that mattered most, reports honestly when a schedule cannot be completed rather than producing something that only looks finished.
My role
I ran the discovery process myself: a stakeholder interview, a review of completed sample schedules, and an availability spreadsheet. I diagnosed why the coordinator's earlier chatbot attempt had failed and turned that diagnosis directly into the architecture: a deterministic rules engine with AI kept out of every scheduling decision. I directed the build with Claude Code as an AI-assisted development partner, reviewing and testing as it went, wrote the 27 scheduling rules from the interview and the sample schedules, and wrote the documentation (project charter through a maintenance guide for whoever takes it over next).
Process
- 1Interviewed the pantry coordinator and reviewed sample completed schedules, an AI-generated meeting summary, and an availability spreadsheet.
- 2Diagnosed why her earlier chatbot attempt had failed: it treated hard rules like break placement as suggestions, and fabricated a schedule when the real data couldn't support one.
- 3Turned that diagnosis directly into the architecture: a deterministic scheduling engine with no AI involved in any decision, enforced by a structural test that fails the build if any AI import ever reaches the scheduling logic.
- 4Directed the build with Claude Code: the scheduling engine, the spreadsheet importer, Excel and PDF exporters, and a server-rendered web interface, reviewing and testing throughout.
- 5Wrote 27 scheduling rules directly from the interview and the sample schedules, each with its evidence documented and every threshold editable without a code change.
- 6Ran the pantry's real availability data through the finished feasibility check and surfaced a real problem: the roster's weekly hour maximums totaled 119 hours against 127.5 hours needed to staff the week, a shortfall invisible in a spreadsheet.
- 7Demonstrated the tool to the coordinator and shipped four of her five follow-up requests before starting formal handover.
Technologies
Only what’s actually in the codebase. Nothing added because it was discussed but not used.
Claude CodePythonFastAPISQLiteJinja2openpyxlGit
Challenges
- Diagnosing a prior AI tool's exact failure mode before designing the fix, rather than assuming more AI would solve what too much AI had already broken.
- Building a structural test that fails the build itself if any AI import ever reaches the scheduling engine, so the boundary is enforced, not just documented.
- The roster was incomplete at the time the rules were specified, so adding a person and their availability had to be a fast, safe, two-minute flow rather than an afterthought.
- Choosing a plain, dependency-light stack on purpose, no build step, no npm, because the coordinator needed someone without David's specific skills to be able to maintain it after he's gone, even though a flashier frontend would look better on a resume.
- Running the coordinator's own data through the finished tool and reporting an uncomfortable finding (the roster can't staff the week as represented) instead of quietly producing a schedule anyway.
Deliverables
- A working scheduling application: dashboard, weekly grid, coverage analysis, call-out and substitute finder, employee roster, and configurable rules
- 27 documented, evidence-backed scheduling rules, editable without a code change
- 349 automated tests
- A quantified staffing-capacity finding in the pantry's real data
- An honest vendor comparison against a commercial scheduling product
- Full project documentation: charter, requirements, architecture, user guide, maintenance guide, and a privacy review
Outcome
The coordinator has a system that encodes her actual rules instead of guessing at them, and that tells her the truth when a week can't be fully staffed instead of quietly producing something that looks done. Running her own data through it surfaced a real, previously invisible problem: the roster couldn't cover the week's required hours, a finding worth more than any schedule the tool could generate. I'm not claiming a time savings yet. The 15-to-20-hour figure is the coordinator's own description of the old process, not a measurement of the new one, and measuring that properly is part of the handover still in progress.
What I learned
- Diagnosing exactly why the coordinator's first AI tool failed, ignoring hard rules and fabricating output when the real answer was 'this can't be done', became the actual architecture brief, not just a footnote.
- Knowing where not to use AI is its own skill. A more AI-heavy build would have demoed better and reproduced the exact failure the coordinator had already lived through.
- The most useful thing the system produced during development wasn't a schedule. It was a finding, and reporting an uncomfortable result honestly mattered more than shipping a feature.
Skills demonstrated
Stakeholder interviewing and discoveryRequirements analysis from conflicting evidenceAI-assisted software developmentClaude CodeDeterministic systems designAI boundary-setting (deciding where AI should not be used, and enforcing it structurally)Automated testingPrivacy-by-design data handlingTechnical documentationHonest vendor evaluation
Visual evidence
Every name shown below is a fictional placeholder, generated by the project's own demo seed script. No real student data appears here or anywhere else this project is shown.
Want to talk through how this applies to your team?