How Replacing Excel With a Custom SaaS Saved a Business Thousands

Most businesses don't outgrow Excel because they grow fast. They outgrow it because the cost of using it slowly compounds: missed updates, duplicate entries, version confusion, and a constant stream of messages asking "what's the current schedule?"

This is the story of how I helped one of those businesses make the switch — and what it actually cost to build, what decisions went into the architecture, and what changed on day one.

The Business

Three physical locations. Fifty-plus employees across retail and operations roles. A team of managers coordinating weekly schedules via shared Excel files, WhatsApp, and paper printouts posted on back-room walls.

The problems weren't dramatic. Nobody was having a crisis every day. But the inefficiencies were constant and cumulative:

• Every schedule change required manual updates across multiple files and notifications across multiple channels
• Conflicts — two employees booked for the same shift, or a shift with nobody assigned — happened regularly and often weren't caught until the day of
• There was no single source of truth. Different managers had different versions of the same week's schedule
• New employees had no way to view their schedule without contacting a manager

The estimated administrative time lost: 8–12 hours per manager per week, across three locations and four managers.

Diagnosing Before Designing

The first thing I do before any design or technical work is a discovery session. I want to understand the actual workflow, not just the pain points as the client describes them.

In this case, the discovery revealed something important: the managers didn't just want a digital schedule — they wanted fewer conversations. The schedule was the trigger for dozens of daily messages: "Am I working Thursday?", "Can I swap Saturday?", "What time does the afternoon shift start?"

The solution wasn't just a schedule viewer. It needed to reduce the surface area for those questions by making information self-serve for employees.

That insight changed the product scope significantly. We needed:

1. Employee-facing views (not just manager dashboards)
2. Real-time updates (changes visible immediately, without refresh)
3. Notification support (push or email when a schedule is published or changed)

Architecture Decisions

Stack: Next.js for the web app, PostgreSQL on Supabase for the database (real-time subscriptions out of the box), hosted on Vercel.

Real-time: Supabase's real-time engine uses PostgreSQL's logical replication to push database changes to connected clients. This gave us live schedule updates without building a WebSocket layer from scratch — a significant time saving.

Auth model: Three roles — Admin, Manager, and Employee. Admins can manage all locations; Managers can manage their assigned location; Employees can only view their own shifts. Row-level security in PostgreSQL enforces this at the database level, not just the application layer.

Schedule data model: I made the intentional decision to store shifts (a specific person, at a specific location, at a specific time) rather than schedules (a weekly template). This makes the data model simpler, conflict detection straightforward, and historical reporting easy.

What We Built in 8 Weeks

Manager dashboard:

• Drag-and-drop weekly schedule builder per location
• Conflict detection (overlapping shifts for the same employee flagged in real-time)
• One-click publish to notify all affected employees
• Bulk shift assignment for recurring patterns

Employee view:

• Personal schedule with a 4-week lookahead
• Shift detail (location, start/end time, manager contact)
• History of past shifts

Notifications:

• Email notifications on schedule publish and changes
• In-app notification center

Admin panel:

• User management across all three locations
• Role assignment and location binding
• Basic reporting (hours per employee, coverage gaps)

Day One

The client ran both systems — Excel and the new platform — in parallel for the first two weeks. This is standard practice for any operational system migration and lets you identify gaps before cutting over completely.

By the end of week two, managers had stopped updating the Excel files. Not because they were told to, but because maintaining both was more work than just using the new system.

The most telling feedback came from an employee, not a manager: "I used to message Ahmed every Sunday night to find out when I was working. Now I just open the app."

The Numbers

After 60 days in production:

• Admin time saved: Managers reported 6–8 hours per week back, per location (12–16 hours total across three locations)
• Schedule conflicts: Dropped from a reported average of 3–4 per week to near zero
• Manager messages about schedules: Reduced by an estimated 70% based on manager self-reporting
• Employee satisfaction: No formal measure, but zero churn in the first 60 days was noted by operations management as unusual

At an average manager hourly cost of $25–35, the 16 hours per week recovered represents $1,600–2,200 in administrative overhead savings every single week.

The Broader Lesson

Custom software gets a reputation for being expensive and slow. That reputation is earned by projects without clear scope, without disciplined discovery, and without someone who understands both the business problem and the technical solution.

When those things are in place — a clear problem, a scoped solution, and a focused build — the ROI timeline is measured in weeks, not years.

---

Dealing with a similar operations problem? Let's talk about what a custom solution could look like for you.