Adding calendars and assignments would have made the product broader, but it also would have moved the boundary away from the one post-schedule question I wanted it to answer.
A shift already has a cleaner, a date, a start time, and a location.
At that point, I don't need another calendar.
I need an answer from the person who was assigned.
That distinction ended up defining a surprisingly large product boundary for the shift-confirmation tool I've been building.
It would be easy to look at a product that stores shifts and assume the next feature should be scheduling: recurring jobs, availability, drag-and-drop assignments, maybe routes after that.
I deliberately kept those things on the other side of the line.
The input is an assignment, not an empty calendar
The workflow starts after somebody has already decided something like:
Cleaner: Maria
Date: Friday
Time: 6:00 PM
Location: North Park office
The product doesn't need to decide whether Maria should get that job.
It needs to ask Maria whether she can actually work that specific assignment.
That gives me a much narrower input:
assigned shift
→ cleaner response
rather than:
customers
+ availability
+ recurring jobs
+ routes
+ staffing rules
→ build schedule
→ cleaner response
Both are legitimate product problems.
They are just very different ones.
Once I treated an existing assignment as the starting point, a lot of product decisions became easier to judge.
Importing shifts from CSV makes sense.
Adding an individual assigned shift makes sense.
Showing that assignment as Unconfirmed makes sense.
Building the system that decided who should be assigned in the first place does not have to be part of the same MVP.
That separation is also how I describe the boundary in the shift confirmation vs scheduling software comparison.
The missing information appears after scheduling
A schedule can say:
Maria → Friday → 6:00 PM
and still leave an operational question unanswered.
Has Maria actually confirmed it?
That missing answer is the part I care about.
For the confirmation side, the useful states are things like:
Unconfirmed
Confirmed
Pending Cover
If the assigned cleaner hasn't responded, the shift remains visible for follow-up.
If they confirm, the uncertainty is removed.
If they say they cannot make it, the job needs a coverage decision.
None of those actions require the product to rebuild the original schedule.
They happen because the schedule already exists.
This was useful for keeping the interface focused too. An owner looking at this part of the process doesn't necessarily need to rearrange next month's entire calendar. They need to see which already-assigned jobs still carry risk before work starts.
Broadening the scope changes the questions
A scheduler has to answer questions that a confirmation layer can mostly avoid.
Who is available?
Who should get this job?
Does this route make sense?
Is this recurring assignment still valid next week?
Should the job move to another day?
How does the new assignment affect the rest of the schedule?
Those are not small additions around the edges of confirmation. They change what owns the source of truth for the schedule.
Once a product starts making those decisions, importing an existing schedule is no longer just an input path. Now you have to decide which system wins when the two disagree.
For the current product boundary, I can use a simpler rule:
the planning system owns the plan; this product owns the response to an assigned shift.
That does mean accepting a limitation.
If a cleaning team needs booking, routing, dispatch, invoicing, or a full job calendar, this isn't the tool that should replace that system.
I'm comfortable with that.
Trying to make every adjacent problem disappear would turn a focused confirmation tool into another operations suite.
Cover is where I had to be careful
Coverage looks like it could pull the product back into scheduling.
A cleaner says they can't make Friday's shift. Another cleaner may be able to take it. Someone has to approve the replacement.
It would be tempting to let the system automatically find an available cleaner and rewrite the assignment.
I kept that boundary narrower too.
The important thing for this workflow is that the original shift remains visibly unresolved while a Cover Request is reviewed. If an owner or admin approves a replacement, that newly assigned cleaner still needs to confirm the shift.
That sequence keeps two decisions separate:
Who should take the shift?
and:
Did that person confirm it?
The first can involve manager judgment.
The second needs an explicit response from the assigned cleaner.
If I merged those together, approving a replacement could accidentally look like the replacement cleaner had accepted the work.
I don't want the software making that leap.
A smaller product can still have a clear boundary
“Not included” can look bad on a feature list.
No scheduling.
No route planning.
No dispatch.
No invoicing.
But those exclusions are useful when they make the product's starting point obvious.
For this one, the boundary is concrete:
The team finishes planning the schedule somewhere else.
The assigned shifts come in.
Then the confirmation work begins.
That gives me a useful test whenever another feature seems adjacent:
Does this help resolve an already-assigned shift, or does it start building the schedule itself?
If it is the second one, I need a much stronger reason to bring it inside the product.
For now, I would rather make the handoff between scheduling and confirmation clear than own both sides badly.
Top comments (0)