At first, I thought shift confirmation would be a small feature.
Someone gets assigned to a job.
They click confirm.
The owner can see it.
That sounded simple enough.
But once I started turning it into an actual MVP, I realized the feature was not really about the button.
It was about everything that happens around the button.
The confirm button was the easy part
The first version in my head was very simple.
A staff member gets a shift.
They see the details.
They click confirm.
Done.
But then I started asking small questions.
What if they do not confirm?
What if they saw the message but forgot to reply?
What if the owner thinks the shift is handled, but the staff member never actually confirmed?
That is when “unconfirmed” stopped being just a label.
It became something the owner needs to notice.
Not because anyone did anything wrong, but because the job time is getting closer and no one wants to find out too late.
“Can’t make it” is not the end of the flow
The other case was even more interesting.
Someone clicks:
Can’t make it
At first, that also sounds simple.
Just mark the person as unavailable.
But the job does not disappear.
The client still expects someone to show up.
The owner still needs to find cover.
Someone else may need to take the shift.
So the shift cannot just become “cancelled.”
It needs to move into another state.
Something like:
This job still exists, but it needs someone else now.
That small difference changed how I thought about the whole flow.
The state became more important than the page
I started thinking less about screens and more about states.
A shift can be waiting for confirmation.
A shift can be confirmed.
A shift can need cover.
A shift can be taken by someone else.
None of these are complicated on their own.
But each one changes what people should see.
The owner needs to know what still needs attention.
The assigned staff member needs a simple action, not a full scheduling system.
A person who might cover the shift needs enough information to decide, but not every private client detail right away.
That last part was something I did not think about at first.
Available shifts needed privacy rules
When I first imagined an “available shifts” page, I thought it would be simple.
Show the open job.
Let someone take it.
But then I realized the details matter.
Before someone accepts a cover shift, maybe they should not see the full address, entry instructions, access notes, or client contact information.
They only need enough to decide:
Can I do this job?
Is the time okay?
Is the area reasonable?
After they accept it, then the full details make sense.
It is a small product decision, but it changes the feeling of the feature.
The page is not just showing open work.
It is controlling when information should become visible.
Time also became less simple than I expected
The same thing happened with time.
A shift is not just a date and time if people are looking at it from different devices or locations.
For a small team, I think it is safer to show everything in the workspace timezone instead of guessing based on each person’s device.
That sounds like a small detail.
But if the time is wrong, the whole product becomes useless.
Someone shows up late.
Someone shows up on the wrong day.
The owner loses trust in the tool.
So even a boring timezone decision becomes important.
What I learned from this part
Building this reminded me that a lot of MVP work is not about adding more features.
It is about deciding what should happen in the boring middle.
What happens after someone clicks confirm.
What happens after someone says they cannot make it.
What the owner needs to see first.
What a staff member should not have to think about.
What information should stay hidden until the right moment.
The confirm button is easy.
The harder part is making sure the button fits into a real workflow.
I am still building this out, and I keep finding small edge cases that were invisible when the idea was only in my head.
That is probably the most useful part of building the MVP.
It forces the messy parts to stop being vague.
