Open questions

Mostly undecided · last reviewed 11 October 2026

A few things about Shiffty are decided — the industry, the shape of the application, the tools it will be built with, including the solver for the first version, where the agent runs, who provides sign-in and who works for whom; 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. Built in the API on 19 October 2026 behind an interface that HiGHS or OR-Tools can take over; not deployed. Since 10 November 2026, on the owner's request, HiGHS solves the week and YALPS stays as a fallback; whether HiGHS replaces it for good is not decided (Agent and solver).

• The agent runs on Agentfy, reached through its partner server chat and one MCP server that Shiffty runs (5 October 2026). Agentfy’s embed widget is not used, and the chat is drawn inside the Shiffty application. See Agentfy integration.

• One agent per store; one company is one Agentfy team (5 October 2026). A store’s manager and employees talk to the same agent, each as themselves. See Agentfy integration.

• An employee belongs to exactly one store in the first version; a manager may manage several (5 October 2026). Replaced on 11 October 2026 by the entry below: a manager now has one store too.

• A store’s agent is created automatically when the store is created (5 October 2026). This needs Agentfy’s operator to switch it on; see what has to be true first.

• Shiffty’s own sign-in, not Neon Auth (6 October 2026). Email and password, kept by Shiffty’s API, as in our other products. See Screens.

• An owner, their stores, the stores' managers and each manager's people (11 October 2026). See Who works for whom below.

• Schedules are shown in the store's time zone, never the viewer's (11 October 2026). Each store has a time zone; the days, "today" and the times of its schedule are the store's, wherever the person looking is. See Data structure.

• One schedule grid for everyone, with a filter (14 October 2026). A store's week shows its managers and its employees in one table, managers first, and a filter chooses whose rows are shown — by role, by the manager people report to, by person and by area. Hours, totals and warnings stay the whole store's whatever is filtered. This reverses the owner's earlier choice (11 October 2026) to keep the team's and the managers' schedules apart, on two tabs, never added together. See Screens.

• No assistant in the app until it is ready; no stand-in for Agentfy (14 October 2026). From 14 to 19 October 2026 each role's Assistant tab said "In development" and that everything is done by hand in the other tabs; the links that would open the assistant were hidden, and neither the scripted demo nor the chat was shown. The API's local stand-in for Agentfy and its tables are removed, and that still holds; the real integration stays. The assistant part was replaced on 19 October 2026 by the entry below.

• The assistant is on again, for good (19 October 2026). The owner tried the whole chain by hand against a local Agentfy and turned the assistant back on. It is shown when the API says it is available to the person — Shiffty is connected to Agentfy, chat is on and their store's agent is ready — and otherwise the Assistant tab says why and who can fix it. The scripted demo is removed, with no scripted fallback. After signing in a person lands on the Assistant tab when it is available, and otherwise on Schedules (the owner, a manager) or My shifts (an employee); the owner, who had no assistant until 20 October 2026, always landed on Schedules and now lands on the Assistant tab too when theirs is available. Built, checked against a local Agentfy only, not deployed. See Agentfy integration and Screens.

• What the assistant may do, and how (19 October 2026). In the end the store assistant does everything the signed-in manager or employee may do in the app, with that person's own rights and through the same rules as the app, deactivating people or deleting shifts included where the person may. It does not approve or decline change requests and does not publish schedules — for now; once a solver is added the agent will build schedules and decide requests, and until then no tool for those exists. There is no assistant for the owner or the whole company: one agent per store, and the owner does the owner's things in the app (replaced on 20 October 2026, below). Tools are written by hand, each the size of a task, not generated from the API. The first step — one catalog of tools and nine read tools — is built, not deployed. See The agent's tools.

• An assistant for the owner (20 October 2026). This replaces "there is no assistant for the owner or the whole company" of 19 October 2026 (above). The owner gets an assistant of their own — one agent per company, next to the stores' agents — with the full range of what the owner may do in the app: every store, managers included. Every change is a card the owner confirms, checked again on confirmation; reading needs no card. Publishing a week is allowed for the owner only, as a card the owner confirms; a manager's assistant still cannot publish. Who is asking and what they may do come only from the signed-in owner, never from the model. Built, tested, checked against a local Agentfy only, not deployed. See The agent's tools and Agentfy integration.

• The solver builds weeks and weighs requests; publishing stays human (19 October 2026). The owner added the solver, called by the agent: it proposes a week for the store's team and weighs a change request, and the agent may prepare a manager's approve or decline. This lifts "no tools to approve or decline until there is a solver" from the entry above, as propose tools: the manager confirms each card in the app, and the confirmation runs the ordinary approve or decline, or writes the week into a draft. Publishing a week stays a person's action, with no tool; so does undoing a decision. Built in the API, tested on the seeded demo stores; its three tools are in the agent's catalog; not deployed. See Agent and solver and The agent's tools.

• The agent reads people's descriptions into the solver's constraints (20 October 2026). The agent turns what a person's description clearly says about when or where they work into constraints for the solver, each with the words it came from, and the manager sees every one, and every one ignored, on the card before confirming; a wrong reading is the manager's to correct. Structured availability fields in a person's profile may come later; not decided. Built in the API and the app, tested, checked once against a local Agentfy; not deployed. See Agent and solver.

• A manager's rights in their own store (19 October 2026, the owner's option 1). Within their store and only for its employees — never another manager, never themselves — a manager deactivates and reactivates a person, changes their manager to another manager of the same store, invites employees and withdraws those invitations, and edits the store's description and opening hours (refused while shifts would fall outside; the time zone stays the owner's). The owner keeps every right, and every change records who made it. Built in the API and the app, not deployed; since the same day the assistant proposes each of them as a card the manager confirms (step 3). See Data structure.

Only sign-in, roles, invitations, schedules, change requests and the assistant's chat are implemented, and only in part — see What is built. No hosted Agentfy is connected; the assistant was checked against a local one only.

Who works for whom

Decided by the owner on 11 October 2026:

• One owner, many stores; a store may have managers; each manager has their own people. An employee reports to a specific manager of the same store, or — since 23 October 2026, the owner's decision — to no manager: a store can be run by the owner alone with a few employees, and the owner then decides those employees' requests.
• The company is the owner's business (for example, a chain called Morgan Retail). There is no list of companies to choose from: each person has exactly one place — the owner has their company, everyone else one store. This replaces "a manager may manage several stores" (5 October 2026).
• Only owners sign up on their own. Managers and employees join through an invitation from the owner (since 19 October 2026 a manager also invites employees to their store); until 15 October 2026 no email was sent and the owner handed the link over — since then it is sent by email (SHIF-25), and can still be handed over.
• An owner joins only after a platform administrator approves them (decided by the owner on 23 October 2026). Signing up is a request to join; until it is approved the owner cannot sign in and is told why. Approving makes the company active and connects its assistant, which since then makes the company's team in Agentfy. The same day, answering questions on the change: a declined applicant may ask again with the same email; a platform administrator can switch an approved company inactive (nobody of it signs in, nothing is deleted) and back; the administrators' letter about a new request says only who asked. Invitations are unchanged. Built; see What is built.
• Existing test data could be dropped, and a demo company is recreated by a seed script on a developer's machine.

Why: this is how the stores we have in mind are run — the owner decides about the managers, a manager about their own people — and the prototypes for the three roles are drawn this way. What a manager may approve for whom follows from it and is built later, with change requests.

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.
• The assistant's tools: choices made while building step 1 (19 October 2026, for the owner to confirm). A conversation's permission now holds capabilities ("schedule.read", "requests.submit") instead of tool names. store_people leaves out people's email addresses. Sending the person's own confirmed request stays a direct action, as it was. Two of the next steps met the rights of that day: a store's description and hours were changed only by the owner, and deactivating people, changing their manager and inviting were the owner's too. The owner gave managers those rights for their own store's employees on 19 October 2026 (above), and they are tools since step 3, built the same day. See The agent's tools.
• The solver: choices made while building it (19 October 2026, for the owner to confirm). The 11 h rest rule is a hard rule for the shifts the solver adds, while by hand it stays a warning. The objective's weights — till-hours short and duty gaps 10,000 an hour, overtime 100 an hour, a changed shift 40, fairness 8 and 1 — are our choice, not measured. A decision confirmed from the assistant's card is recorded as decided by the manager ("person"), not "by the assistant". A manager's plan does not touch the managers' rows, which are the owner's, so manager-on-duty gaps are reported, not filled. See Agent and solver.
• Sign-in in the demo. The plan for 18 October uses a role switch instead of real sign-in; whether it stays that way is to confirm, now that a minimal real sign-in exists (6 October 2026). See Two weeks to a demo.
• Everything technical beyond the tools. Hosting, the language model, notifications, and where employee data is kept. 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. Since 14 October 2026 the usual till receipts per hour can be typed in by hand; whether stores can export them, and how they would become a number of people, is still open; the day view's fixed ratio of receipts per cashier (16 October 2026) is one answer, for the owner to confirm.
• Descriptions of stores and people, and who sees them (built 14 October 2026, for the owner to confirm). A store and each person have a plain-text description, meant as context for the assistant later; nothing reads them yet. Three choices were made while building and wait for the owner: a person never sees their own description, and a manager sees only those of their store's employees, not of other managers (privacy); a manager describes any employee of the store, not only their own people; and the store's managers, not only the owner, change its hourly load, because they know their traffic. See Data structure.
• One grid and its filter (built 14 October 2026, for the owner to confirm). Three choices were made while building. A manager sees the same rows as before — their store's managers too, read only — so nothing was widened; whether managers should keep seeing the other managers' rows is the owner's question. The list of a store's weeks now shows shifts, hours and overtime of everyone together, since the grid has no groups any more. Moving to another store keeps the role and area in the filter but drops the chosen people and manager, who belong to the store before. See Screens.
• Split shifts (built 14 October 2026, for the owner to confirm). A person may now work several shifts on one day, such as 12:00–14:00 and 18:00–20:00; shifts on one day may touch but not overlap. Open: whether three a day is the right limit (chosen while building); whether shifts on one day need a minimum gap between them (none now); and whether a person may take only part of a split day off — time off and a cover now take every shift of the day, while a swap and a change of hours stay about one shift. See Data structure.
• A reason with every decline (the owner's rule, built 14 October 2026). When the manager or the owner declines a change request they must say why, in 3 to 500 characters (limits confirmed by the owner, 14 October 2026), and the requester sees it. Open for the owner: whether a colleague who says no to covering or swapping should also be able to give a reason — optional, as the colleague is not deciding — or stay as now, without one; and that Undo clears the reason, so a later decline asks again. See Data structure.
• Who approved a change (the owner's rule, built 14 October 2026). The schedule, My shifts, the shift dialog and the lists of requests say who approved a change, or "Approved automatically". A decision records how it was made — a person, automatically or the assistant — although only a person decides today. Decided by the owner (14 October 2026): managers see who changed the schedule — the owner and every manager of the store see on the grid who approved each change, so a manager also sees "Approved by Alex Morgan" on another manager's shift; employees see it on their own shifts, in My shifts. Open for the owner: whether anything should approve automatically at all, and which changes; and that past decisions without a person count as automatic (there are none: until now an approval had to name a person). See Data structure.
• The day view and the month sheet (built 16 October 2026, for the owner to confirm). Three choices were made while building. How people are counted per hour: in person-hours — a person counts for the part of the hour they are there, minus a break whose start is known; a break without a start time is not taken off, so that person counts as there for the whole shift. Tills needed = receipts ÷ receipts per cashier per hour, rounded up, at least one while the store is open — a new store setting, 80 unless changed, edited by the owner and the store's managers like the hourly load. The contract for a month = weekly hours × days of the month ÷ 7, so a partly covered week counts by its days in the month; days off count only in weeks that have a schedule. See Data structure.

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.