DEV Community: Miran

What I Learned Adding Email Notifications to a Small SaaS MVP

Miran — Tue, 09 Jun 2026 03:00:22 +0000

When I first thought about adding email notifications to a small SaaS MVP, I imagined it as a simple feature.

Something happens in the app.

Send an email.

Done.

That was the clean version in my head.

But once I started thinking through the actual workflow, I realized notifications are not really just about sending messages.

They are about timing, trust, failure, and making sure the right person gets the right information at the right moment.

That made the feature feel a lot more important than I expected.

Sending the email is only one part

The obvious part of an email notification is the actual email.

A shift is assigned.

A staff member gets notified.

Someone says they cannot make it.

The owner gets notified.

A shift needs cover.

Available staff get notified.

That sounds straightforward.

But the more I thought about it, the more I realized that “send an email” is not enough as a product rule.

The system also needs to know:

Who should receive it?

When should they receive it?

What exactly should the email say?

What should happen if the email fails?

Should the app show that the notification was sent?

Should the owner be able to tell who has already been notified?

Those questions matter because notifications are usually invisible once they leave the app.

If the product does not track them clearly, everyone starts guessing.

A notification should reduce uncertainty

For a scheduling tool, the goal of a notification is not just to tell someone something.

The goal is to reduce uncertainty.

If a staff member gets assigned a shift, the notification should help them respond.

If someone cannot make it, the notification should help the owner act quickly.

If a shift needs cover, the notification should help another staff member decide whether they can take it.

The email is not the product.

The response after the email is the product.

That changed how I thought about the feature.

The email should not just say:

You have a shift.

It should make the next action obvious.

Confirm the shift.

Say you cannot make it.

Review a shift that needs cover.

Open the app to see details.

A notification that does not lead to a clear next step is just more noise.

Timing matters more than I expected

The next thing I had to think about was timing.

Some emails should probably go out immediately.

For example, when a new shift is assigned.

Or when someone says they cannot make it.

But reminders are different.

A reminder too early can be ignored.

A reminder too late is useless.

A reminder sent at the wrong time can make the product feel unreliable.

So the timing rule matters.

If a shift starts tomorrow morning, maybe the reminder should go out the day before.

If a shift starts in two hours and still has no confirmation, maybe the owner needs to see that sooner.

If a shift already needs cover, the reminder should not act like everything is normal.

The notification system has to understand the state of the shift.

It cannot just send the same message on a fixed schedule without context.

State should decide the message

This connects back to the status design.

A confirmed shift should not get the same kind of notification as a shift waiting for confirmation.

A shift that needs cover should not get the same message as a normal assigned shift.

A recently reassigned shift might need a different kind of update.

The status should shape the email.

That sounds obvious, but it is easy to forget when building.

It is tempting to create one generic notification template and reuse it everywhere.

But generic notifications can create confusion.

If the email is too vague, the user still has to figure out what happened.

That is not helpful.

The email should answer a simple question:

What changed, and what do I need to do now?

If the email cannot answer that, it probably should not be sent yet.

Failed emails need to be visible

This is one of the parts I almost ignored.

What happens if an email fails?

Maybe the email address is wrong.

Maybe the provider rejects it.

Maybe the account hits a sending limit.

Maybe the message gets delayed.

From a technical perspective, the app tried to send it.

But from the user’s perspective, the person may never receive it.

That is a big difference.

If the product silently fails, the owner may think the staff member was notified when they were not.

That can create the same mess the tool is supposed to prevent.

So I think the app needs at least some basic visibility around notification status.

Not a huge notification analytics system.

Just enough to answer:

Was the email sent?

Did it fail?

Should the owner try another way?

That small piece of visibility can protect trust.

Notifications should not spam people

Another thing I had to think about is frequency.

If the system sends too many emails, people will start ignoring them.

That is almost worse than not sending them at all.

For a small MVP, I think notifications should be limited and intentional.

Send when something important changes.

Send when someone needs to take action.

Send reminders only when they are actually useful.

Do not send an email for every tiny update.

Do not remind someone five times if nothing has changed.

Do not notify the whole team when only one person needs to know.

The product should be careful with attention.

Email is useful because people check it.

But that usefulness disappears if the product becomes noisy.

The owner needs context, not just alerts

Owner notifications are different from staff notifications.

A staff member usually needs a simple action.

Confirm this shift.

Review this available shift.

See the updated details.

But the owner often needs context.

Who declined?

Which shift needs cover?

How soon is it?

Has anyone accepted it yet?

Was anyone notified?

Does the owner need to step in?

That means owner emails should probably be more specific.

Not long.

Not complicated.

Just clear enough that the owner understands the situation quickly.

The owner should not have to open three pages just to understand why they got the email.

The message should make the next decision easier.

The MVP version should stay simple

I do not think the first version needs a complex notification engine.

It does not need dozens of templates.

It does not need advanced automation rules.

It does not need every possible setting.

But it does need clear defaults.

For the MVP, I would start with a few basic notification types:

New shift assigned.

Shift waiting for confirmation.

Staff says they cannot make it.

Shift needs cover.

Shift has been reassigned.

Email failed or needs attention.

That is probably enough to support the core workflow.

The important part is not having many emails.

The important part is making each email useful.

The app should remember what it sent

This is another small detail that feels important.

If the system sends a notification, the app should probably remember it.

Not forever in a complicated way.

But enough to show a simple history.

Sent to Alex at 8:30 AM.

Reminder sent yesterday.

Cover request sent to available staff.

Email failed.

That kind of record helps the owner trust the system.

It also helps with debugging.

If someone says they never got the email, the owner can at least see what the app attempted.

Without that, the app becomes a black box.

And black boxes are stressful when the work depends on people responding.

What I learned from thinking about this

The biggest lesson is that notifications are not just a technical add-on.

They are part of the workflow.

A notification changes what people know.

It changes what they are expected to do next.

It can reduce uncertainty.

Or it can create more uncertainty if it is vague, late, noisy, or invisible when it fails.

That is why I want to think about notifications as product behavior, not just email delivery.

The question is not only:

Did the app send an email?

The better question is:

Did the right person get the right message at the right time, with a clear next action?

For a small SaaS MVP, that is probably the real notification feature.

Why Time Zones Matter Even in a Small Scheduling Tool

Miran — Mon, 08 Jun 2026 00:58:30 +0000

When I first started thinking about shift scheduling, I did not expect time zones to be something I would care about early.

The tool is for small teams.

The shifts are simple.

Someone has a job at a certain time.

How complicated can that be?

That was my first thought.

But the more I worked through the product flow, the more I realized that time is one of those boring details that only feels boring until it is wrong.

A shift time is not just a number

At first, I thought of a shift as a date and a time.

May 12.
9:00 AM.
Four hours.

That sounds clear.

But the question is:

9:00 AM where?

The owner might create the shift from one location.

A staff member might view it on another device.

The browser might have a different timezone setting.

Someone might be traveling.

The server might store the time in UTC.

The workspace might operate in one local area.

Most of the time, nobody thinks about this.

Until the time shows up wrong.

Then it becomes a real product problem.

Device time feels convenient, but it can be risky

One tempting approach is to use the user’s device timezone.

That feels natural.

The browser knows the local timezone.

The phone knows the local timezone.

So just show the time based on that.

But for scheduling work, I do not think that is always the safest default.

If the business operates in one location, the shift should probably be shown in the business or workspace timezone.

Not whatever timezone the viewer’s device happens to be using.

A cleaning team in Los Angeles does not want a 9:00 AM job to look different because someone opened the page while traveling.

The job is not moving.

The viewer is.

That distinction matters.

The workspace should probably own the schedule time

The rule I am leaning toward is simple:

The workspace timezone should be the source of truth for scheduled shifts.

That means when the owner creates a shift, the time belongs to the workspace.

When staff view the shift, they see it in that same workspace timezone.

When notifications are sent, they should be based on that workspace schedule.

This makes the experience more predictable.

Everyone is talking about the same 9:00 AM.

The owner does not have to wonder what the staff member’s device converted it to.

The staff member does not have to guess whether the time is local to them or local to the job.

The product should make that obvious.

The hard part is not storing the time

The technical part is not only about storing timestamps.

That part is important, but it is not the whole problem.

The product also has to decide what the time means.

Is this timestamp an absolute moment?

Is this a local business time?

Should the UI convert it?

Should the notification system convert it?

What happens if the workspace timezone changes later?

What happens if a staff member is outside the area?

What happens if daylight saving time changes?

These are the kinds of questions that make time feel bigger than it looked at first.

The code can store a date.

But the product has to define the rule.

Bad timezone handling breaks trust quickly

This is why I think time zones matter even in a small MVP.

If a color is slightly off, users may not care.

If a card has too much spacing, users may still understand the product.

But if the shift time is wrong, trust disappears fast.

Someone shows up late.

Someone shows up on the wrong day.

The owner has to message everyone again.

The tool becomes one more thing to double-check.

That is the opposite of what a scheduling product should do.

A scheduling tool has to be boringly reliable.

Especially around time.

Notifications make this even more important

Time zones also affect reminders.

If a shift starts at 9:00 AM, when should the reminder go out?

Two hours before?

The night before?

The morning of?

Those reminders only make sense if the system is using the right schedule time.

If the app mixes device time, server time, and workspace time without a clear rule, reminders can become confusing.

A reminder that arrives too early is annoying.

A reminder that arrives too late is useless.

A reminder based on the wrong timezone is worse than no reminder because it gives false confidence.

So the notification system has to follow the same time rule as the schedule.

One source of truth.

One interpretation.

No guessing.

The UI should say less, but mean more

I do not think the UI needs to explain time zones everywhere.

Most users do not want to read a timezone lesson.

They just want to know when the shift starts.

But the product should still be clear.

If the workspace timezone is used, maybe the UI should show that in a small, quiet way.

Something like:

Times shown in Los Angeles time

Or:

Workspace timezone: America/Los_Angeles

Not on every line.

Not as a scary warning.

Just enough so people understand the rule.

The best version is probably one where users do not have to think about it most of the time, but they can still see what the product is doing.

This also affects editing

Creating a shift is one part.

Editing a shift is another.

If the owner changes a shift from 9:00 AM to 10:00 AM, that change should be understood in the workspace timezone.

If the staff member receives a notification, it should match that updated workspace time.

If the shift was already confirmed, the product may need to show that something changed.

Maybe the staff member should confirm again.

Maybe not for every small edit.

I am still thinking about that part.

But it shows how one timezone decision can affect the rest of the workflow.

Time is connected to status.

Time is connected to notifications.

Time is connected to trust.

It is not isolated.

The MVP rule I would start with

For the first version, I would keep the rule simple.

Each workspace has one timezone.

All shifts are created in that workspace timezone.

All staff see shift times in that workspace timezone.

All reminders are calculated from that workspace timezone.

The server can still store timestamps in a safe format.

But the product rule should stay consistent:

The schedule belongs to the workspace, not the viewer’s device.

That is probably enough for the MVP.

Not a full global scheduling system.

Not every possible timezone edge case.

Just a clear default that prevents the most confusing mistakes.

What I learned from thinking about this

Time zones are one of those details that are easy to postpone.

They do not feel like the main feature.

They do not look exciting in a screenshot.

They do not make the landing page sound better.

But they sit underneath the whole scheduling flow.

If the product is wrong about time, everything else becomes questionable.

The dashboard can be clean.

The status labels can be clear.

The notifications can be well written.

But if the shift time is wrong, the system failed.

That is why I am trying to think about timezone rules early.

Not because I want to overbuild.

But because small scheduling tools still need one very clear answer to a boring question:

What time does this shift actually start?

What Should Staff See Before They Accept a Cover Shift?

Miran — Sun, 07 Jun 2026 01:29:25 +0000

When I started thinking about the available shifts page, I thought it would be simple.

A shift needs cover.
Other staff can see it.
Someone accepts it.
The shift becomes covered.

That was the clean version.

But then I ran into a question that felt small at first:

What should staff see before they accept the shift?

At first, my answer was simple too.

Show the shift details.

But the more I thought about it, the less obvious that felt.

Because “shift details” can mean a lot of things.

It can mean the date and time.

It can mean the rough location.

It can mean the client name.

It can mean the full address.

It can mean entry notes, access instructions, contact information, or internal notes from the owner.

Those are not all the same.

And they probably should not all become visible at the same moment.

Enough to decide, not everything

The first rule I am leaning toward is simple:

Before someone accepts a cover shift, they should see enough to decide.

Not everything.

They probably need to know:

The date.

The time.

The rough area.

The type of work.

Maybe the estimated duration.

Maybe whether it is a normal job or something unusual.

That is enough for someone to answer the basic question:

Can I take this?

But they probably do not need the full address yet.

They probably do not need entry instructions yet.

They probably do not need client contact information yet.

They probably do not need private notes from the owner yet.

That information matters later.

But maybe not before the shift is actually theirs.

Visibility is part of the product flow

This is the part I almost missed.

I was thinking about the available shifts page as a list.

Just show open work.

But it is not only a list.

It is also a visibility boundary.

The page decides when information becomes visible and to whom.

That makes it more important than a normal list view.

If the page shows too little, staff cannot decide whether they can take the shift.

If it shows too much, the product exposes details before it needs to.

The right answer is probably somewhere in the middle.

Show enough to make the action possible.

Hide enough to keep the workflow respectful.

That balance is a product decision, not just a UI decision.

The owner sees a different story

The owner’s view is different.

The owner needs to understand the full state of the shift.

Who was originally assigned?

Who said they cannot make it?

Is the shift still uncovered?

Who is eligible to cover it?

Has someone accepted it?

Does the owner still need to do anything?

That is a lot more information than a staff member needs.

And that is fine.

Different users should not always see the same version of the same object.

The owner is managing the workflow.

The staff member is responding to one part of it.

If both views show everything, the product starts to feel heavier than it needs to be.

The staff view should stay narrow

For staff, I keep coming back to the same idea:

Keep the view narrow.

Most staff members do not want an admin dashboard.

They do not need the whole schedule.

They do not need to understand every state behind the shift.

They need a clear action.

Can I do this shift?

Do I have enough information to decide?

What happens if I accept it?

That is probably enough.

A narrow staff view is not a limitation.

It is part of making the product easier to use.

The less someone has to think, the more likely they are to respond quickly and correctly.

Details can unlock after accepting

The flow I am thinking about now is something like this:

Before accepting, the staff member sees limited details.

Date.

Time.

Rough location.

Job type.

Maybe a short note.

Then they tap:

I can cover this.

The server checks whether the shift is still available.

If the claim succeeds, the shift becomes theirs.

After that, more details can appear.

Full address.

Entry instructions.

Client notes.

Any private job details they actually need to do the work.

That feels cleaner to me.

The product is not hiding useful information forever.

It is just showing information at the right moment.

This also helps with trust

There is a trust layer here too.

If owners feel that every available staff member can see too much too early, they may hesitate to use the feature.

If staff feel they are being asked to accept a shift without enough context, they may ignore it.

Both sides need the product to feel reasonable.

That is why the visibility decision matters.

It is not only about privacy.

It is also about confidence.

The owner should feel safe opening a shift for cover.

The staff member should feel informed enough to accept it.

A good flow has to support both.

Some details are not equal

This is where I started mentally separating the shift details into levels.

Basic decision details:

Date.
Time.
Rough area.
Job type.
Duration.

Operational details:

Exact address.
Entry instructions.
Supplies needed.
Parking notes.
Client-specific instructions.

Sensitive or private details:

Client contact information.
Internal notes.
Access codes.
Anything the owner would not want widely visible.

I am not saying this is the final model.

But even thinking in these levels helps.

It stops me from treating “show shift details” as one big decision.

There are different kinds of details.

They should probably have different visibility rules.

The MVP does not need a complicated permission system

I do not want to overbuild this.

The first version does not need a huge permission engine.

It probably does not need dozens of custom rules.

It probably does not need owners configuring every field one by one.

That would be too much for the MVP.

But the basic rule should be clear:

Before accepting, show only decision-level details.

After accepting, show the details needed to complete the job.

That is a simple default.

And simple defaults are useful.

They keep the product understandable while still leaving room for more control later.

What I learned from thinking about this

This feature reminded me that privacy is not always a separate settings page.

Sometimes privacy is inside the workflow.

It is in the moment when a shift becomes visible.

It is in the question of who can see what before taking action.

It is in the difference between browsing an available shift and being assigned to it.

That is easy to miss when building the UI.

A card can look simple.

A list can look simple.

A button can look simple.

But behind that card is a decision about visibility.

For this MVP, I think the better default is:

Show just enough before the action.

Show more after the responsibility is accepted.

That keeps the flow simple.

It keeps the staff view focused.

And it makes the available shift page feel less like a public board and more like a controlled handoff.

How I Use AI to Find Edge Cases Before Building a Feature

Miran — Sat, 06 Jun 2026 03:57:38 +0000

One thing I have been using AI for lately is not writing code first.

It is finding the weird parts of a feature before I build it.

That sounds less exciting than generating an app from a prompt.

But honestly, it has been more useful.

When a feature is still in my head, it usually feels simple.

A staff member gets a shift.
They confirm it.
The owner sees the status.

Or someone cannot make it.
They tap a button.
Another person covers the shift.

Clean enough.

But once I start asking what can go wrong, the feature gets more real.

That is where AI has been helpful.

Not as the person making the product decisions.

More like a patient reviewer that keeps asking annoying questions.

The first version of an idea is usually too clean

When I describe a feature to myself, I naturally describe the happy path.

The user does the expected thing.

The system responds correctly.

The page updates.

Everyone understands what happened.

That is the version I want to build because it is easy to picture.

But real workflows are not usually that clean.

Someone does not respond.

Someone responds late.

Two people click the same button.

A shift changes after it was already confirmed.

Someone should not see all the details yet.

The owner needs to know what changed, but the staff member does not need the whole admin view.

None of these are strange cases once you think about them.

But I often do not see them when I am only thinking about the main flow.

I use AI to slow the feature down

The main thing AI helps me do is slow the feature down.

Instead of jumping straight from idea to page, I ask it to walk through the flow step by step.

For example:

What happens before the user clicks this button?

What happens immediately after?

Who needs to know?

What should change on the page?

What should not change yet?

What happens if the user clicks twice?

What happens if another person acts at the same time?

What happens if the action fails?

These questions are simple.

But they force the feature to become more specific.

And a specific feature is much easier to build than a vague one.

I do not ask AI to decide the product

This is the part I try to be careful about.

AI can generate a lot of possible rules.

Some of them are useful.

Some of them are too complicated.

Some of them sound smart but do not fit the actual product.

So I do not treat the answer as the final decision.

I treat it as a list of things to inspect.

For example, AI might suggest a full approval system, priority ranking, advanced eligibility rules, notification queues, audit logs, and role-based visibility.

Some of that might be right later.

But for an MVP, not all of it belongs in the first version.

The useful question is not:

Can this be more complete?

It is:

What is the smallest rule that keeps the workflow clear?

That question still has to come from me.

AI can help me see the options.

It cannot know which tradeoff is right for the product.

A small example: the cover shift flow

The cover shift flow looked simple at first.

A staff member says they cannot make it.

The shift becomes available.

Someone else takes it.

The owner sees that it is covered.

But when I asked AI to look for edge cases, more questions came up.

What if two people try to take the shift?

What if the original staff member changes their mind?

What if the owner already assigned someone manually?

What if the shift starts soon?

What if the person trying to cover it should not see the full address yet?

What if the claim fails?

What should the second person see?

Those questions changed the shape of the feature.

The UI was no longer just a button and a card.

There had to be a rule behind the button.

There had to be a clear state after the action.

There had to be a polite failure message if someone was too late.

That is the kind of thing I want to find before writing too much code.

Edge cases are not always extra features

I used to think edge cases were mostly things you handle later.

Build the main version first.

Clean up the weird parts later.

Sometimes that is still true.

But I am starting to see that some edge cases are not really optional.

They are part of the core workflow.

If two people can claim the same shift, that is not a rare technical detail.

It affects whether the schedule can be trusted.

If someone can see private job details before accepting a shift, that is not just a UI detail.

It affects what information the product exposes.

If the owner cannot tell whether a shift is confirmed or still waiting, that is not a small visual issue.

It affects the whole reason the product exists.

So I try to separate two types of edge cases.

Some are future complexity.

Some are core clarity.

AI is useful for listing both.

Then I still have to decide which ones matter now.

The prompt that usually helps me

The most useful prompt is not very fancy.

It is usually something like this:

Here is the feature I am building. Walk through the workflow as different users. Find the edge cases, unclear states, permission issues, and failure cases. Do not add big new features. Focus on what would make the MVP confusing or unreliable.

That last part matters.

If I do not say that, the answer can become too big.

AI will happily design a full enterprise system if I let it.

But I am not trying to build everything.

I am trying to find the parts that would make the first version break trust.

That is a smaller and more useful goal.

I still need to decide what to ignore

The hardest part is not getting suggestions.

The hard part is deciding what to ignore.

AI can make a feature feel bigger than it needs to be.

It can turn one button into ten flows.

It can make the MVP feel like it needs admin approvals, complex permissions, advanced logs, and detailed rules before anything ships.

That is dangerous.

So after I get the edge cases, I try to sort them into three groups.

Must handle now.

Can handle with a simple default.

Can ignore until real users prove it matters.

For example, double-claiming the same shift probably needs to be handled now.

A full eligibility ranking system probably does not.

A simple “already covered” message might be enough for the first version.

That sorting step is where product judgment still matters.

What this changes before coding

Doing this before coding changes the build in a few ways.

The database model becomes clearer.

The status names become clearer.

The UI actions become narrower.

The error messages become less surprising.

The dashboard knows what needs attention.

The staff view does not accidentally become an admin view.

It also helps me write better implementation prompts.

Instead of asking for a vague feature, I can ask for a specific flow.

Not:

Build a cover shift feature.

But:

When a shift needs cover, show limited details to eligible staff. Let one staff member claim it. The server should confirm the claim only if the shift is still open. If another person already claimed it, show a simple already-covered message.

That is much easier to build.

And much harder to misunderstand.

What I learned from using AI this way

The biggest lesson is that AI is more useful when I give it a smaller job.

Not:

Build my product.

But:

Help me see what I am missing.

That is where it has been the most helpful.

It does not replace product thinking.

It makes product thinking harder to avoid.

It forces me to write down the flow.

It shows me where my words are vague.

It gives me possible failure cases.

Then I still have to choose what belongs in the MVP.

For small tools, that has been a good balance.

AI helps me move from a clean idea to a more realistic workflow.

But the product still has to be decided by the problem, not by the prompt.

The Dashboard Should Show What Needs Attention, Not Everything

Miran — Thu, 04 Jun 2026 13:56:49 +0000

When I first thought about the dashboard for a small scheduling tool, I imagined something pretty standard.

A calendar.
A list of upcoming shifts.
Some staff names.
Some status labels.

That felt like the obvious place to start.

If the product is about scheduling, the dashboard should probably show the schedule.

But the more I worked through the MVP, the less convinced I became.

Because a schedule can show everything and still fail to show the thing that matters most.

A full schedule can still hide the problem

This was the part I kept coming back to.

A dashboard can look complete.

Every shift has a time.
Every job has a staff member.
Every row has a status.
Nothing looks obviously broken.

But that does not mean the owner is done.

One shift might still be waiting for confirmation.

Another one might need cover.

Someone may have clicked “can’t make it.”

A shift might be starting soon, but no one has clearly accepted it yet.

All of that can be inside the dashboard.

But if the owner has to scan the whole page to find it, the tool is still asking them to do too much work.

At that point, the product is showing data.

It is not really helping.

The first screen should not be “everything”

My first instinct was to put as much as possible on the dashboard.

Upcoming shifts.
Recent activity.
Staff availability.
Confirmation status.
Maybe a calendar view.
Maybe some quick actions.

It felt useful in theory.

But when I imagined someone actually using it during a busy day, it started to feel heavy.

Small team owners are not usually opening the dashboard because they want to admire a clean schedule.

They are opening it because they need to know what needs attention.

Did everyone confirm?

Is anything uncovered?

Did someone back out?

Is there a shift starting soon that still has no clear answer?

Those questions are more important than showing every single piece of information at once.

So the dashboard probably should not start with everything.

It should start with the things that are not settled yet.

“Needs attention” is a different kind of dashboard

Once I thought about it that way, the dashboard changed in my head.

It was no longer just a schedule overview.

It became more like a triage page.

What is fine?

What is waiting?

What is risky?

What needs a decision?

That feels closer to the real job of the dashboard.

Not to replace the full schedule.

The full schedule still matters.

But the first screen should reduce the amount of remembering the owner has to do.

The owner should not have to think:

I need to check if Alex confirmed.

I need to remember that Jamie said they cannot make it.

I need to find out whether someone took that open shift.

I need to scroll back through messages.

Those things should be pulled forward.

Because those are the things that can turn into problems later.

A calendar view can be too calm

This is something I did not expect to think about.

Calendars are very good at showing time.

But they are not always good at showing uncertainty.

A calendar box can look normal even when the shift is not actually settled.

The job is still there.

The time is still there.

The assigned person is still there.

Visually, it can feel handled.

But the real state might be:

Waiting for confirmation.

Needs cover.

Recently reassigned.

Starting soon with no response.

That kind of uncertainty needs a different kind of visual priority.

Maybe it belongs above the calendar.

Maybe it belongs in an attention list.

Maybe it needs a small count at the top.

I am not completely sure yet.

But I am pretty sure that a clean calendar alone is not enough.

It can make messy things look calmer than they really are.

The dashboard should answer the owner’s next question

The question I keep asking now is simple:

What does the owner need to know next?

Not what data exists.

Not what page looks most complete.

What do they need to know next?

If everything is confirmed, the dashboard can be quiet.

That is good.

But if three shifts need attention, those should be obvious.

If a cover request is still open, it should not be buried.

If someone has not confirmed and the shift is close, that should feel different from a shift two weeks away.

The dashboard should help the owner decide where to look first.

That is the part I missed at the beginning.

I was thinking about the dashboard as a place to display the product.

Now I am thinking about it as a place to reduce uncertainty.

Not every status needs the same weight

This connects to the status design too.

A confirmed shift does not need much attention.

It should be visible, but calm.

A waiting shift might need light attention.

A shift that needs cover should be much harder to miss.

A recently reassigned shift might need a little context, so the owner understands what changed.

These statuses should not all look equal.

If every card is visually the same, the owner has to do the sorting manually.

That is exactly what I want the product to avoid.

The interface should make the next action easier to find.

Not louder than necessary.

Not full of red alerts everywhere.

Just clear enough that the owner does not have to keep the real state of the schedule in their head.

The full schedule still matters

I do not think the dashboard should remove the full schedule.

There still needs to be a place to see everything.

Sometimes the owner wants the whole picture.

Sometimes they want to check tomorrow.

Sometimes they want to review who is assigned to which job.

That view is still useful.

But I am starting to think it should not be the only main view.

There is a difference between:

Here is everything on your schedule.

And:

Here is what needs your attention right now.

For this MVP, the second one feels more important.

The full schedule can be one click away.

The problems should be closer.

What I learned from this

This is a small product decision, but it changed how I think about the dashboard.

A dashboard should not just show what exists.

It should show what matters first.

That sounds obvious after writing it down.

But when building an MVP, it is easy to start with the page that looks like the category.

Scheduling tool?

Build a calendar.

Task tool?

Build a list.

CRM?

Build contacts.

Sometimes that is right.

But sometimes the better starting point is the messy part.

The thing waiting for a decision.

The thing that might become a problem.

The thing the user is trying not to forget.

For this scheduling flow, I think the dashboard should start there.

Not with everything.

With what needs attention.

Designing Shift Statuses for a Small Team Scheduling Tool

Miran — Wed, 03 Jun 2026 05:04:25 +0000

One thing I did not expect to spend much time on was shift statuses.

At first, I thought this part would be simple.

A shift is either confirmed or not confirmed.

That was the first version in my head.

But once I started thinking through the actual workflow, that felt too flat.

Because in a real schedule, “not confirmed” can mean a few different things.

It can mean the staff member has not seen the shift yet.

It can mean they saw it but have not replied.

It can mean they said they cannot make it.

It can mean someone else needs to cover it.

It can mean someone already took it, but the owner still needs to know what changed.

Those are very different situations.

If the product treats all of them the same, the owner still has to figure out the real story manually.

And that is exactly the kind of mess the tool is supposed to reduce.

A status is not just a label

The first mistake I almost made was thinking of status as a label on a card.

Confirmed.

Unconfirmed.

Cancelled.

That looks fine in a UI mockup.

But a status is not only something the user reads.

It decides what the product does next.

It changes what actions are available.

It changes what the owner needs to see.

It changes what the staff member can do.

It changes whether the shift should appear in an urgent area, an available shifts list, or a normal schedule view.

That made me realize the status model needed more thought than I expected.

Not because the MVP needs to be complicated.

But because even a small workflow can become confusing if the states are too vague.

The first status: assigned

The most basic state is assigned.

Someone has been placed on a shift.

But assigned does not mean confirmed.

This distinction matters.

A schedule can look complete because every shift has a person attached to it.

But if those people have not confirmed, the schedule is still not really settled.

So I started separating these two ideas:

Who is currently assigned?

And has that person confirmed?

Those sound similar, but they answer different questions.

The owner needs both.

Assigned tells you who is supposed to do the job.

Confirmed tells you whether that person has actually acknowledged it.

Without that distinction, the schedule can look cleaner than it really is.

Waiting for confirmation

The next state is waiting for confirmation.

This is probably the quietest state, but it matters a lot.

Nothing dramatic has happened yet.

No one declined.

No one missed the shift.

No one made a mistake.

But the owner still does not have a clear answer.

That is the uncomfortable part.

A shift that is waiting for confirmation is not a crisis.

But it is also not done.

The product should make that visible without making it feel like an emergency too early.

This is where timing matters.

Waiting for confirmation two days before the job is normal.

Waiting for confirmation thirty minutes before the job is very different.

The status might be the same, but the urgency is not.

That is something I think the dashboard should probably care about later.

Confirmed

Confirmed is the easiest state to understand.

The staff member saw the shift and said yes.

The owner can stop worrying about that specific handoff.

But even here, I think the product should be careful.

Confirmed should not mean the shift can never change.

People still get sick.

Plans still change.

Someone can still say they cannot make it later.

So confirmed is not the end of the entire workflow.

It is just the current clear state.

That sounds obvious, but it matters when designing the flow.

A confirmed shift still needs a path into another state if real life changes.

The product should not trap the shift just because it was once confirmed.

Needs cover

This is the state that changed how I thought about the whole product.

When someone says they cannot make it, the shift should not just become unconfirmed again.

That loses important context.

It is not the same as someone who simply has not replied.

The person did reply.

Their answer was no.

So the shift now has a different problem.

It needs cover.

That status is useful because it tells the owner what kind of action is needed.

Not “wait for a reply.”

Not “check if they saw it.”

Find someone else.

This is why I think “needs cover” deserves to be its own state.

It makes the problem more specific.

And specific problems are easier to act on.

Available to cover

Once a shift needs cover, it may become visible to other staff.

But I do not think that should be the same state as “needs cover.”

Needs cover describes the problem.

Available to cover describes who can act on it.

That difference matters.

From the owner’s side, the shift needs attention.

From the staff side, the shift may appear as something they can take.

Same shift.

Different view.

Different meaning.

This is where status and permissions start to overlap.

The owner may see the full story.

The available staff may only see enough information to decide whether they can take it.

The product has to decide what each person sees at each stage.

That is why the status model cannot be separated from the user roles.

Reassigned

If someone else takes the shift, the status should become reassigned or covered.

I am still thinking about the exact wording.

“Covered” sounds simple.

“Reassigned” makes the change more visible.

Either way, the important thing is that the owner should no longer feel like the shift is unresolved.

Someone else has taken responsibility for it.

The schedule has a new assigned person.

The original person should probably no longer see it as their active shift.

The new person should now see the full details.

That means reassignment is not only a label.

It changes visibility.

It changes responsibility.

It changes who gets the next notification.

That is the part I want the system to make clear.

Cancelled should mean something different

I also think cancelled needs to stay separate.

A cancelled shift means the job itself is no longer happening.

That is different from a shift that still exists but needs another person.

This seems like a small distinction, but mixing these two would create confusion fast.

If a staff member cannot make it, the shift is not cancelled.

If the client cancels the job, then the shift is cancelled.

Those are different events.

They should not share the same status.

Otherwise, the owner may not know whether they need to find cover or remove the job completely.

The product should not make that ambiguous.

The simple model I am thinking about

Right now, the basic model in my head looks like this:

Assigned

Waiting for confirmation

Confirmed

Needs cover

Available to cover

Reassigned or covered

Cancelled

Completed

That might still change.

Some of these may become separate fields instead of one status.

For example, assigned person and confirmation status might be better separated.

Cover availability might be more of a visibility rule than a core shift status.

I am not completely sure yet.

But writing the states out has already helped.

It forced me to see where I was using one word to describe multiple situations.

What I learned from this

The biggest lesson is that status design is product design.

It is easy to treat statuses like small UI details.

But they shape the whole workflow.

They decide what users see.

They decide what actions are possible.

They decide what should be urgent.

They decide when information becomes visible.

They decide whether the owner has to keep the real state of the schedule in their head.

For a small MVP, I do not want to overbuild this.

But I also do not want the states to be so vague that the tool creates more confusion.

A good status should make the next step obvious.

That is probably the standard I want to use.

If the status does not help someone understand what should happen next, it probably needs to be clearer.

What Happens When Two People Try to Cover the Same Shift?

Miran — Tue, 02 Jun 2026 05:59:04 +0000

After writing about the cover flow for missed shifts, I kept thinking about one small moment that is easy to ignore:

What happens if two people try to cover the same shift?

On the screen, the flow looks simple.

A shift needs cover.

Available staff can see it.

Someone taps “I can cover this.”

The shift becomes covered.

That is the clean version.

But real products usually get messy in the small gap between someone tapping a button and the system deciding what actually happened.

The UI can be fast, but it cannot decide the truth

The tempting version is to make the UI feel instant.

Someone taps the button, and the shift immediately looks like theirs.

That feels nice.

The product feels quick.

The action feels clear.

The user gets feedback right away.

But there is a problem.

The UI does not know if someone else tapped the same button at almost the same time.

Maybe two staff members saw the available shift.

Maybe both wanted it.

Maybe both tapped within a few seconds of each other.

If both screens show success, the product just created a new problem.

Now two people may think they are covering the same shift.

That is worse than the shift being uncovered.

Because now the owner has to clean up the confusion created by the tool.

The server should make the final call

For this kind of flow, I think the UI can feel responsive, but the server has to be the source of truth.

The staff member can tap “I can cover this.”

The app can show a loading state.

Maybe even something friendly like:

Checking availability...

But the shift should only become theirs after the server confirms it.

The backend needs to check a few things before accepting the claim.

Is this shift still open?

Does it still need cover?

Has someone else already taken it?

Is this staff member allowed to take it?

If all of that passes, the claim succeeds.

If not, the claim should fail in a normal, human way.

Not with a scary error.

Just something like:

This shift has already been covered.

That is enough.

The person does not need to know about race conditions or database locks.

They just need to know they were a little too late.

First valid claim wins

For the MVP, I would probably keep the rule simple:

First valid claim wins.

But the word “valid” matters.

It is not the first person who opened the page.

It is not the first person who saw the shift.

It is not the first person whose UI changed locally.

It is the first claim that reaches the server and passes the checks.

That feels like a good default for a small product.

It is simple enough to understand.

It avoids double assignment.

It gives the owner one clear answer.

And it keeps the staff experience straightforward.

Someone got it.

The shift is covered.

Move on.

There are more advanced versions later.

The owner could approve claims manually.

The system could rank people by distance, availability, or experience.

Some staff could get priority.

But for the first version, I would rather have one reliable rule than five clever rules that create more confusion.

The database has to protect the rule

This is the part that is not very visible in the UI, but it matters a lot.

The frontend should not be the only thing preventing two people from claiming the same shift.

Disabling the button after someone taps it is not enough.

Two requests can still arrive close together.

Someone can have the page open in two tabs.

A slow connection can make the order feel different from what actually happened.

So the backend or database needs to protect the rule.

The important idea is simple:

Only update the shift if it is still available.

If the shift has already been claimed, the second request should not overwrite it.

That sounds like a small backend detail.

But it is exactly the kind of detail that decides whether the product feels trustworthy.

A scheduling tool cannot be “mostly right” about who is assigned.

It has to be clear.

The owner should not resolve the product’s race condition

This is where the technical detail becomes a product detail.

If two people think they got the same shift, the owner is forced back into manual coordination.

They have to message one person.

Then message the other.

Then explain what happened.

Then update the schedule again.

At that point, the tool did not reduce uncertainty.

It just moved the uncertainty somewhere else.

That is the thing I want to avoid.

The whole point of the cover flow is to make a messy handoff clearer.

If the system creates another messy handoff, the feature failed.

So claim logic is not just a backend edge case.

It affects trust.

The owner needs to believe that when the tool says a shift is covered, it is actually covered.

The staff member needs to believe that when the tool says they got a shift, they really got it.

Eligibility can come later, but the shape matters now

There is another layer here too: eligibility.

Not everyone should necessarily be able to cover every shift.

Maybe someone is not available at that time.

Maybe they are too far away.

Maybe they do not know that client.

Maybe they should not see full job details until they accept.

For the first MVP, I would not try to build a full rules engine.

That feels too heavy.

But I do think the claim flow should leave room for rules later.

The basic question is not only:

Can this shift be claimed?

It is also:

Can this person claim this shift?

That is a slightly different product shape.

Even if the first version only checks simple things, the model should probably be ready for more specific rules later.

The flow I am thinking about

The claim flow in my head looks like this:

Staff taps “I can cover this”

The app sends the claim request

The server checks whether the shift still needs cover

The server checks whether this person is allowed to claim it

If yes, the shift becomes reassigned

If no, the staff member sees that the shift is no longer available

The owner sees one clear covered state

Nothing fancy.

But it solves the important part.

Only one person gets the shift.

The schedule stays clear.

The owner does not need to clean up the product’s mistake.

What I learned from thinking about this

This is one of those features where the UI makes the problem look smaller than it is.

A button can look simple.

A card can move from one state to another.

A shift can look covered.

But the real product is the rule behind the movement.

Who is allowed to claim it?

What happens if two people try at the same time?

Who gets the final state?

What does the second person see?

What does the owner need to know?

That is the part I want to get right.

Not in an overbuilt way.

Just enough so the product does not create more confusion when real life gets messy.

For small tools, I keep finding that the most important work is not always the screen.

Sometimes it is the quiet rule behind the screen.

Building a Cover Flow for Missed Shifts

Miran — Sat, 30 May 2026 04:22:56 +0000

I started working on the cover flow for missed shifts, and it became more interesting than I expected.

At first, I treated it like a simple status change.

Someone cannot make a shift.

They tap a button.

The shift becomes available for someone else.

That was the clean version in my head.

But once I tried to turn it into an actual product flow, I realized there are a few small decisions hiding inside that button.

It is not really a cancelled shift

This was the first thing I had to separate.

If a staff member says they cannot make it, the job itself is not gone.

The client still expects someone to show up.

The time is still on the schedule.

The owner still needs someone assigned to it.

So I did not want to treat it like a cancellation.

It is more like:

This shift still exists, but the current person is no longer covering it.

That sounds small, but it changes the whole flow.

The shift is not confirmed anymore.

It is not completed.

It is not cancelled.

It needs cover.

That one state became the center of the feature.

The owner needs to see the problem quickly

Once a shift needs cover, the owner should not have to dig through the full schedule to find it.

That is something I keep noticing while building this MVP.

A tool can technically show all the information and still fail at the important part.

If something needs attention, it should be hard to miss.

So the owner view should probably not start with the question:

What shifts exist?

A better question is:

Which shifts need a decision right now?

A missed shift should move into a visible place.

Not hidden inside a calendar.

Not treated like a normal upcoming shift.

Not buried under confirmed jobs.

It needs to stand out because someone still has to solve it.

The staff side should stay simple

The staff side is different.

A staff member should not need to understand the whole scheduling system.

They just need a clear action.

For the person who cannot make it, the action is simple:

I can’t make it

For someone who might cover the shift, the action is also simple:

I can cover this

That sounds obvious, but I think it matters.

If the staff view starts feeling like an admin dashboard, the product is probably doing too much.

Most people do not want another system to manage.

They just want to know what they need to respond to.

So the staff flow needs to stay narrow.

Here is the shift.

Here is what you can do.

Here is what happens next.

That is enough.

The available shift should not show everything

This was the part I almost skipped.

When a shift needs cover, other staff may need to see it.

But how much should they see before accepting it?

At first, I imagined showing the full job details.

That would be easy to build.

But then I thought about it more.

Before someone accepts the shift, do they really need the full address?

Do they need entry notes?

Do they need client contact information?

Probably not.

They need enough information to decide whether they can take the job.

The date.

The time.

The rough area.

The type of work.

After they accept it, the full details can appear.

That feels like a better default.

The available shift page is not just displaying work.

It is also deciding when certain information should become visible.

That is a small product decision, but it changes the feeling of the feature.

The flow needs a clean ending

Another detail I had to think through was the ending.

If someone takes the open shift, what happens next?

Does the original staff member still see it?

Does the new person become assigned immediately?

Does the owner need to approve it first?

Should the shift keep a small history of what happened?

I do not think every MVP needs a full audit log on day one.

That would probably be too much.

But the product should at least make the current state clear.

Who is assigned now?

Is the shift covered?

Does the owner still need to do anything?

That is the real purpose of the flow.

Not just to let someone click a button.

The goal is to remove uncertainty.

The version I am thinking about now

Right now, the simple version looks something like this:

Assigned

↓

Staff says they cannot make it

↓

Shift needs cover

↓

Other staff can see limited details

↓

Someone accepts the shift

↓

Shift becomes reassigned

↓

Owner sees it as covered

This is not complicated.

But writing it out helped me see the product more clearly.

The important part is not the number of steps.

The important part is making sure each person sees the right thing at the right time.

What I learned from this

The cover flow reminded me that small products still need careful state design.

Not enterprise-level complexity.

Just enough structure so the product does not become confusing when real life gets messy.

A missed shift is not just one event.

It affects the owner.

It affects the original staff member.

It affects the person who might cover it.

It affects what information should be visible.

It affects whether the schedule can still be trusted.

That is why I like building this kind of small workflow.

The feature looks simple from the outside.

But once you build it, you start seeing the decisions that were hiding underneath.

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.