BLOG ▶ ARTICLE
CASE FILE6 MIN READ

How We Built a Scheduling System That Saved 8 Hours a Week

How We Built a Scheduling System That Saved 8 Hours a Week

The starting point was not dramatic. It was a spreadsheet. Multiple tabs. Volunteer names, shifts, notes, cancellations, confirmations, and a whole lot of color-coding. It worked, technically, the way a house of cards works technically.

The staff spent 5-8 hours every week keeping the schedule alive. That is a huge tax on a small team, especially when the mission is caring for animals rather than managing rows in a spreadsheet.

▶ The first version

We did what good builders do: start small. A Google Sheets script handled the most repetitive parts of the scheduling workflow. It generated assignments and sent notifications automatically. Immediate relief. Fast feedback. Low risk.

That first version proved the concept. Once the workflow was stable, we knew it was worth turning into a proper product.

▶ The full platform

Next came the React frontend, the Express API, and a PostgreSQL database hosted on Railway. The result was a real scheduling platform with volunteer management, shift scheduling, public schedule viewing, and assignment tracking.

This mattered because the system was no longer a tool for the staff alone. It became infrastructure for the organization.

▶ The result

Manual coordination disappeared. Staff time came back. Volunteers had a clearer experience. Most importantly, the shelter could focus on the mission instead of the mechanics.

That is the pattern every small business should pay attention to: if a workflow hurts enough, it is probably not a workflow problem. It is a software problem.

▶ Frequently asked questions

How do I know if my scheduling spreadsheet has turned into a software problem?

The rule of thumb is simple: if a workflow hurts enough, it is probably not a workflow problem but a software problem. In the shelter's case, the warning signs were a spreadsheet with multiple tabs, heavy color-coding, cancellations and confirmations, and staff spending hours every week just keeping the schedule alive. That is a big tax on a small team whose real job is something else.

Why start with a Google Sheets script instead of building a full app right away?

Starting small gave immediate relief, fast feedback and low risk. A Google Sheets script took over the most repetitive parts of scheduling by generating assignments and sending notifications automatically. That first version proved the concept. Only once the workflow was stable did it make sense to turn it into a proper product.

What features did the full scheduling platform end up including?

The full platform included volunteer management, shift scheduling, public schedule viewing and assignment tracking. That mattered because the system stopped being a tool for staff alone and became infrastructure for the whole organization, with volunteers able to view the schedule too.

What actually changed for the staff and volunteers after the switch?

Manual coordination disappeared and staff time came back. Volunteers got a clearer experience. Most importantly, the shelter could focus on its mission of caring for animals instead of the mechanics of managing rows in a spreadsheet.

What technology was the scheduling platform built on?

The platform was built with a React frontend, an Express API and a PostgreSQL database hosted on Railway. That setup replaced the earlier Google Sheets script once the workflow had proven stable and worth turning into a real product.

Want help automating a workflow like this?

▶ BOOK A DISCOVERY CALL