Open questions

Mostly undecided · last reviewed 2 October 2026

A few things about Shiffty are decided — the industry, the shape of the application and the tools it will be built with, including the solver for the first version; everything else is a question to answer before building anything.

Decided so far

• Retail only (25 September 2026). No restaurants, warehouses or generic workforce scheduling. See Overview.
• One application for managers and employees, on phones through Capacitor for now (2 October 2026). See Architecture.
• A NestJS API and a Nuxt application, organised by CleanSlice — the tools our other products are built with (2 October 2026). See Architecture.
• YALPS as the solver for the first version (2 October 2026). Later, most likely Google OR-Tools as a separate service in Kubernetes — an intention, not a decision. See Agent and solver.

None of these is implemented.

Market

• Why us over Deputy and similar tools? See the market overview, the competitive landscape and Deputy and our angle. Auto-scheduling is standard, and large vendors already claim natural-language swaps with manager approval. We need a reason a store manager would recognise, not a feature list, and we need it before Deputy or a similar tool adds an employee-facing chat.
• Which retail segment first? The industry is settled: retail only. Still open: single stores or small chains, grocery or other store formats.
• Which country first? Ukraine and its neighbours are the natural candidates given our experience, and the landscape shows no conversational scheduling tool there yet. Labour rules and messenger habits differ by country, so this choice shapes the first version.
• Who pays and how much? No pricing has been decided. Small-business tools list $2–9 per user per month or $30–120 per location, so the price has to be justified by manager hours saved.

Problem validation

• How much time do managers spend on scheduling today?
• How often does a schedule change after publication, and who handles it?
• What does over- and under-staffing cost a typical store?

The plan is to answer these by talking to store managers we know, starting with people who ran sliding shifts with us.

Product

• Agent or solver. Our working assumption is that the agent translates requests into constraints and a solver builds the schedule. See Schedule generation and Agent and solver. This needs a prototype to confirm.
• A messenger as a second channel. The first channel is our own app. Whether employees can also write from Telegram, Viber or WhatsApp is open. See Employee assistant.
• Everything technical beyond the tools. Database, hosting, language model, notifications. See Architecture.
• Approval. The manager approves every change in the demo. Whether managers find that acceptable is still something to learn; automatic approval is outside the plan.
• Traffic data. Which sources stores actually have. See Input data.

Risks

• Labour law. Rules differ by country and contract. Who is responsible when a generated schedule breaks one?
• Employee data. Availability, absences and personal reasons are sensitive. Where the data lives and who sees it must be settled before any pilot.
• Trust. A manager who does not understand why the agent chose a shift will redo it by hand.

Next step

The next step is the two-week demo plan: a web-only MVP for 18 October 2026, using one seeded, made-up store. The manager would approve every change. This replaces the immediate proposal to start with real store data; testing with a real store remains later work, not an existing pilot.