What Looked Simple Until I Started Building the MVP

Miran — Fri, 29 May 2026 04:00:48 +0000

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.

The Messy Part Usually Starts After the Schedule Is Sent

Miran — Wed, 27 May 2026 07:32:00 +0000

I used to think scheduling problems were mostly about making the schedule.

Put the right person on the right job. Pick a time. Send it out.

That sounds like the hard part.

But the more I looked at small teams, the more I started noticing something else: the messy part often starts after the schedule is already sent.

Someone sees the message but does not reply.

Someone says they cannot make it, but now someone has to remember who might be able to cover.

A job is still on the calendar, but no one is completely sure whether the assigned person actually confirmed.

None of this looks dramatic at first.

It is just one missed reply.
One unclear handoff.
One small assumption.
One message buried somewhere in a thread.

But when the job time gets closer, those little gaps start to feel much bigger.

I find this kind of problem interesting because it is not really about a lack of effort. Most of the time, people are already trying. They are texting, calling, checking notes, scrolling back through messages, and keeping too much in their head.

The issue is that the responsibility is spread across too many places.

One person knows part of the story.
Another person saw a message.
Someone else forgot to reply.
The owner is trying to connect all of it in real time.

That is the kind of small operational problem I want to build around.

Not huge systems.
Not another complicated tool that tries to manage everything.

Just small tools that make one messy part clearer.

It is a small problem, but it repeats.

And I think repeated small problems are often more useful to study than big dramatic ones.

They are quiet.
They are boring.
They are easy to ignore.

But they are also where a lot of real work gets stuck.

DEV Community: Miran