Skip to content
← Back to Blog
March 14, 2026 · 5 min read · Elias Teubner
#ai #typescript #react #case-study

Building Smart Scheduling — AI for Real Business Problems

A hospitality client came to us with a problem I've seen a hundred times: shift scheduling. Every week, the same headache — who works when, which roles are covered, who's on vacation. They were doing it with spreadsheets, WhatsApp messages, and sticky notes. We thought: we build AI tools for a living. We can fix this.

The Problem

Manual shift scheduling in hospitality is a nightmare. Think about it:

  • Several locations with different staffing needs
  • Different roles — Kitchen, Service, Bar, Cleaning — each needing specific people
  • Contract types — full-time, part-time, minijob — each with different hour limits
  • Vacation and sick days that change every week
  • Coverage rules you have to hit, or Friday night lands understaffed

One mistake means an understaffed shift. And in hospitality, that's not just inconvenient — it's lost revenue and stressed-out staff.

The Solution

I built a visual week planner. The time grid spans 6 AM to 10 PM. Every shift carries a role color, so one glance shows what's covered and what isn't. The key features:

  • Drag-and-drop scheduling — click a time slot, assign a person, done
  • Coverage indicators — each day shows green (fully staffed), yellow (cutting it close), or red (understaffed)
  • Employee management — contract hours, availability, vacation tracking all in one place
  • AI assistant — a built-in chat that can analyze the current schedule and suggest optimizations

The Tech Stack

const stack = {
  frontend: 'React + TypeScript',
  backend: 'NestJS',
  database: 'Azure SQL',
  hosting: 'Azure Web Apps',
  ai: 'Claude API',
};

Why NestJS over Express? The business logic is complex — contract hour calculations, role coverage checks, vacation conflict detection. NestJS gives me structure with decorators, modules, and dependency injection. Express would have turned into spaghetti fast.

The AI Part

The built-in KI-Assistent is where it gets interesting. It can analyze the current week's schedule and spot problems, suggest optimizations based on contract hours and role coverage, and consider all constraints automatically.

The hardest part wasn't the AI itself — it was making the suggestions useful for someone who isn't technical. The client doesn't care about prompt engineering. They want to click "optimize" and get a better schedule. That meant shaping how the AI delivers its suggestions — clear, specific, and ready to act on.

For my own workflow I use each AI tool where it's strongest — Claude for coding and architecture, Gemini for research and product testing, Copilot for Microsoft/Azure-related work and debugging, and ChatGPT occasionally for a second opinion.

What I Learned

Building for real clients teaches you things that building for yourself never will:

  1. Requirements change when someone actually uses it. I built the first version with a complex drag-and-drop system. The client wanted simple click-to-assign. I shipped the complex version anyway — learned the lesson the right way, then shipped the version that actually worked for them.
  2. "Good enough" ships faster than "perfect." The first version shipped without the AI assistant. Just a visual planner — and 10x better than spreadsheets. That gap matters more than any feature on the backlog.
  3. Non-technical users don't read documentation. The interface has to be self-explanatory. If you need to explain how your tool works, the tool isn't done yet.

The Best Part

The client uses it. Every week. Without being asked, without needing support, without reverting to spreadsheets. That's the only metric that matters — not downloads, not stars, not a polished demo. Just a real person solving their real problem with something I built. That's the job.

— Elias

Share this post