DEV Community: Clean Labs

What I Learned Building Reliable Android Reminders

Clean Labs — Thu, 24 Sep 2026 21:51:36 +0000

Building a task app with reminders taught me something I didn't fully appreciate at the beginning:

A reminder is not a single Android feature. It is a chain of systems that all have to work together.

The user sees one simple thing:

"Remind me at 3 PM."

Behind that, Android may be dealing with alarms, background execution, battery restrictions, notification permissions, notification channels, device-specific behavior, and time zones.

After working through these problems while building Wumilo, I started thinking about reminder reliability very differently.

A reminder is a chain, not an API call

It is tempting to think about reminders as:

task time → alarm → notification

In reality, there are several points where things can go differently from what the user expects:

User creates reminder
        ↓
App stores the reminder
        ↓
App schedules the system event
        ↓
Android decides when the event can run
        ↓
The app handles the event
        ↓
Android delivers the notification
        ↓
Notification settings determine how it is presented

That distinction matters when debugging.

If a reminder doesn't appear, the problem isn't necessarily the scheduling code.

The alarm may have been scheduled correctly while the notification was blocked.

Or the notification may be configured correctly while Android delayed background activity.

Or everything may work normally until the phone enters a deeper idle state.

Once I started looking at reminders as a delivery chain, debugging became much more useful.

Exact alarms solve one part of the problem

One of the first Android concepts that becomes important when building time-sensitive reminders is the exact alarm system.

An exact alarm is about when Android should trigger a scheduled event.

That is important for something like:

"Remind me at 3:00 PM."

But an exact alarm does not automatically guarantee that the user will see a notification at 3:00 PM.

There are still other parts of the system involved.

Notification permission, notification channels, Do Not Disturb, lock-screen settings, and device-specific restrictions can all affect what the user experiences.

I wrote a separate explanation of this distinction here:

Understanding exact alarms and Android reminders

The important lesson for developers is simple:

Precise scheduling and successful notification delivery are related, but they are not the same problem.

Battery optimization is another layer

Android's power-management features make sense from the phone's perspective.

A phone that allows every application to run freely in the background would waste battery quickly.

The challenge is that a reminder application is specifically asking the operating system to do something later.

That creates a tension between:

saving battery
limiting background activity
running scheduled work
delivering time-sensitive events

Doze and App Standby are part of Android's power-management model, while some manufacturers add their own restrictions on top.

This means two phones running the same Android application can behave differently.

A developer can have a reminder that works perfectly during development and still receive reports from users whose devices handle background activity more aggressively.

That's why I stopped treating battery optimization as a simple "bug."

It is often part of the environment in which the application is running.

I documented the Android side of this separately:

How battery optimization can delay Android reminders

Samsung made the problem even more interesting

Testing on one Android phone is not enough.

Samsung devices have their own battery-management behavior and settings around apps that can be put to sleep.

That can be especially relevant for applications that need to do something later without the user actively opening them.

This was one reason I ended up separating general Android battery behavior from Samsung-specific guidance.

The general Android concepts are useful everywhere.

The device-specific settings are not.

For developers, this is a good reminder that "Android" isn't always a single environment in practice.

An application can use the same APIs while the surrounding system behavior differs between manufacturers and device configurations.

For the Samsung-specific side, I keep a separate guide:

Samsung Sleeping Apps and Android Reminders

Notifications are a separate failure point

Another lesson was not to assume that an alarm and a notification are the same thing.

Modern Android has its own notification system, including:

notification permissions
notification channels
notification importance
Do Not Disturb and other interruption controls
lock-screen notification settings
device-specific notification controls

Android 13 also introduced the POST_NOTIFICATIONS runtime permission for many apps.

So when someone says:

"My reminder didn't show."

There are several questions worth asking.

Did the scheduled event happen?

Did the application handle it?

Was a notification created?

Was the notification channel enabled?

Does the app have notification permission?

Was the phone suppressing or hiding the notification?

Those questions lead to much better debugging than simply checking whether the reminder was saved.

Time zones turned out to be a product problem

Time zones were another area where the technical details quickly became product decisions.

Suppose someone creates a reminder for 9:00 AM and then travels somewhere in a different time zone.

What should happen?

There isn't one universally correct answer.

A reminder can represent a particular instant in time, or it can represent a local clock time that should follow the user.

Those are different concepts.

For a task application, the expected behavior matters more than simply converting a timestamp.

This is why time-zone handling needs to be considered part of the reminder model, not just something added to date formatting later.

I ended up documenting the behavior separately because it is easy to overlook until users actually travel:

Android Reminders and Time Zones

Restarting the phone is an important test

One of the simplest tests is also one of the easiest to forget.

Create a reminder.

Restart the phone.

Wait for the reminder.

It sounds obvious, but rebooting changes the lifecycle of the application and the Android environment.

For a reminder app, I also want to think about scenarios such as:

the app hasn't been opened for a while
the screen is locked
the device is idle
battery-saving features are active
notifications have been restricted
the device has been restarted
the user changes time zones
the user changes notification settings
the reminder is scheduled far into the future

A reminder system isn't really finished when it works immediately after pressing "Save."

It needs to work when the application isn't currently in front of the user.

Testing the whole delivery chain

This changed how I think about testing reminder features.

A unit test can tell me that a reminder time was calculated correctly.

It cannot fully reproduce what happens when Android, the device manufacturer, battery management, and notification settings all get involved.

So I find it useful to think about testing in layers.

Application layer

Does the task store the correct reminder information?

Does editing or deleting the task update the scheduled reminder correctly?

Scheduling layer

Was the system event scheduled for the expected time?

What happens when the reminder is changed?

What happens when it is deleted?

Device layer

What happens during idle?

What happens after reboot?

What happens when battery restrictions are enabled?

Notification layer

Does the notification appear?

Is the notification channel enabled?

What happens when notification permission is denied?

Time layer

What happens when the device time zone changes?

What happens when daylight-saving rules are involved?

The more layers I tested, the more obvious it became that "the reminder code works" isn't the same as "the reminder feature works."

Don't solve everything by telling users to disable battery optimization

There is also a temptation to make troubleshooting simple:

"Disable every battery restriction."

That can sometimes make a particular problem disappear, but it isn't a great universal solution.

Battery management exists for a reason.

Users shouldn't have to turn their phone into a permanently unrestricted environment just to use a task app.

A better approach is to understand which restriction is actually relevant, explain what it can affect, and give users targeted guidance when necessary.

That also makes support documentation more useful.

Instead of:

"Android is killing the app."

You can explain what the relevant Android or manufacturer setting does and why changing it may help.

The biggest lesson: reliability is partly a UX problem

The most interesting thing I learned is that reminder reliability isn't purely an engineering problem.

It is also a communication problem.

The user doesn't care which Android subsystem caused the failure.

They care that they asked their phone to remind them about something and whether they can trust it.

That means a reminder app needs more than scheduling code.

It needs:

sensible defaults
predictable behavior
useful diagnostics
clear settings
good testing
honest limitations
troubleshooting guidance that matches the actual device

The more complicated the operating system becomes, the more important that last part gets.

What I would do differently on a new reminder project

If I were starting another reminder application today, I would think about reliability much earlier.

I'd define the reminder lifecycle before implementing the UI:

Create
  ↓
Persist
  ↓
Schedule
  ↓
Survive lifecycle changes
  ↓
Trigger
  ↓
Notify
  ↓
Verify / troubleshoot

I'd also test on more than one Android device and treat manufacturer-specific behavior as something to investigate rather than something to assume away.

Most importantly, I'd avoid designing the system around the assumption that one Android API controls the entire experience.

It doesn't.

A practical checklist for developers

Before calling a reminder feature "done," I'd want to be able to answer these questions:

Is the reminder stored reliably?
Is the scheduled time calculated correctly?
Does the scheduling mechanism match the precision the feature requires?
What happens when the device is idle?
What happens after a reboot?
What happens under battery restrictions?
What happens on manufacturer-customized Android versions?
Does the app have the notification access it needs?
Are notification channels configured correctly?
What happens when notifications are suppressed?
What happens when the user changes time zones?
Can users understand what to check when something goes wrong?

If several of those answers are unknown, the reminder system probably isn't finished yet.

Final takeaway

Building reliable Android reminders changed my mental model of the feature.

I started with something that looked simple:

Schedule something for later.

I ended up with something closer to:

Store the user's intention
        ↓
Schedule it at the right time
        ↓
Work within Android's power-management model
        ↓
Handle the device lifecycle
        ↓
Trigger the event
        ↓
Deliver a notification
        ↓
Make the result visible to the user

That is a much bigger system.

And that is probably the most useful lesson I've taken from building Wumilo:

When a mobile feature depends on something happening later, don't test only whether you can schedule it. Test whether the entire chain can deliver it.

I’ve Been Building Money For My Beer Since 2019. Here’s What I’ve Learned

Clean Labs — Mon, 21 Sep 2026 22:59:41 +0000

In September 2019, I started a website with a pretty straightforward idea.

I wanted to find legitimate ways to make a little extra money online.

I called it Money For My Beer.

The name was intentionally a little silly. The idea wasn't to get rich. It was about finding practical opportunities that could give you a bit of extra breathing room. Maybe enough for dinner, a weekend trip, a hobby, or, yes, a cold beer after a long week.

Six years later, the site has become something quite different from what I originally imagined.

Money For My Beer is still about money and side hustles, but it has gradually grown into a place where I research and write about technology, business, SEO, security, reviews, travel, gardening, beer, and practical how-to topics.

And because I'm a developer and technical architect by profession, I’ve realized that running the website itself has become almost as interesting to me as writing for it.

From a Side-Hustle Blog to Something Bigger

The original concept was simple.

Find an opportunity.

Try to understand it.

Explain it.

Help someone decide whether it might actually be worth their time.

That philosophy is still there, but my interests expanded.

I started writing about things I was already curious about. Technology. Websites. SEO. Security. Business ideas. Practical problems. Things I had learned myself. Things I wanted to understand better.

Eventually, Money For My Beer became less about one narrow topic and more about useful information from the perspective of someone who likes figuring things out.

That change wasn't planned as some grand content strategy.

It happened naturally.

And I think that's one of the most interesting things about running a website for years. You can start with one idea and discover that the project becomes something completely different along the way.

I'm Not an Expert on Everything

One thing I've become more conscious of over the years is the difference between writing about something and actually being an expert in it.

I'm a technical architect. I work with software, apps, websites, and digital systems. Those are areas where I have professional experience.

That doesn't mean I automatically know everything about investing, taxes, cybersecurity, gardening, travel, or every other subject that might appear on the site.

So my role is often less about saying, "I'm the expert," and more about saying:

Here's what I found. Here's what the reliable sources say. Here's how I understand it. And here's what you should probably verify for yourself.

For topics where accuracy matters, I try to use authoritative sources, distinguish facts from opinions, and update articles when information changes.

That's especially important when you're publishing anything involving money, security, products, services, or technology.

SEO Changed How I Think About Content

Running Money For My Beer has also given me a completely different appreciation for SEO.

It's one thing to read an SEO guide.

It's another thing to publish hundreds of pages and then watch how real people discover them.

I spend a lot of time looking at Google Search Console, search queries, impressions, clicks, click-through rates, indexing, internal links, titles, descriptions, and the overall structure of the website.

Google's own documentation emphasizes creating helpful, reliable, people-first content rather than producing pages primarily to manipulate search rankings.

That's something I've increasingly tried to take seriously.

Search Console is particularly useful because it lets me see what people actually search for and which pages Google is showing them.

And sometimes the search data tells you something completely different from what you expected.

That's one of my favorite parts.

You publish something thinking people will find it through one topic, and months later you discover that they're finding it through a completely different question.

That becomes another opportunity to improve the article.

The Hard Part Isn't Always Writing

Writing an article is relatively straightforward.

Maintaining a website isn't.

Over time, you accumulate:

old articles
outdated information
weak pages
duplicate topics
messy categories
broken links
unnecessary pages
outdated internal links
URLs that no longer make sense
content that seemed useful five years ago but isn't anymore

Eventually, you have to decide what deserves to stay.

I've spent a significant amount of time cleaning up Money For My Beer rather than simply publishing more.

I've reorganized categories, improved internal linking, rewritten older content, updated important pages, reviewed site policies, and tried to make the overall website easier to understand.

It's not particularly glamorous work.

There isn't a screenshot you can post on Twitter showing how exciting a better category structure is.

But it's part of building a website that you actually intend to keep around.

The Website Is Also a Technical Project

Because I come from a development background, I naturally end up looking at the site as more than just a collection of articles.

There is the WordPress side.

There is performance.

There is indexing.

There are redirects and canonical URLs.

There is HTTPS and security.

There are structured pages, categories, internal links, metadata, and the XML sitemap.

There is also the slightly less glamorous part of making sure everything still works after changing something.

A content website might look simple from the outside.

Underneath, there are plenty of systems to maintain.

And that's one reason I still enjoy working on it.

It gives me a place to experiment with ideas outside of my day job.

I Also Don't Want It to Become a Content Factory

This is probably one of the biggest lessons I've learned.

It is incredibly easy to look at SEO and think:

I need more articles.

Then you publish another article.

Then another.

Eventually you have hundreds of pages, but not necessarily a better website.

I've become much more interested in making existing content better.

Can an old article answer the question more clearly?

Can two related pages be connected with better internal links?

Can I remove something outdated?

Can I explain a complicated concept in simpler language?

Can I add useful context instead of just repeating information that already exists everywhere else?

Those questions are much more interesting to me than simply trying to hit a publishing quota.

Why the Name Still Works

The funny thing is that the name Money For My Beer still makes sense to me.

Not because the website is literally about beer money anymore.

The beer is really the metaphor.

It's about finding useful opportunities, learning something, making something, or solving a problem that makes everyday life a little better.

Sometimes that means learning about a side hustle.

Sometimes it's understanding a technology problem.

Sometimes it's figuring out SEO.

Sometimes it's researching a product.

Sometimes it's just reading about something interesting.

The subject can change.

The underlying idea doesn't have to.

Building Something That Outlives the Original Idea

When I started Money For My Beer in 2019, I wasn't trying to build a huge media company.

I wanted a place to publish things I found useful.

Years later, I'm still doing that.

The website has changed.

The topics have changed.

My approach to SEO has changed.

My approach to research has changed.

Even the way I think about what makes a good article has changed.

But the core reason I keep working on it is surprisingly similar to when I started.

I like building things.

I like researching things.

I like figuring out how things work.

And I like taking something complicated and turning it into something another person can actually understand.

That's probably the most accurate description of Money For My Beer today.

It isn't just a blog about making extra money.

It's a long-running side project where I get to follow my curiosity and share what I learn.

What's Next?

I don't have some giant five-year publishing plan.

I'll probably keep improving the site, cleaning up older content, experimenting with SEO, writing about things that interest me, and occasionally following a completely unexpected rabbit hole.

That's part of the fun.

For now, you can see what I'm working on at Money For My Beer, read the story behind the site, or explore some of the newer guides and experiments.

And if you're also building a small website, side project, blog, or weird little internet business of your own, I'd genuinely be interested in hearing about it.

Sometimes the projects that start as "I'll just try this" end up sticking around much longer than expected.

Cheers.
Ryan

I Built a To-Do App Because I Was Tired of To-Do Apps

Clean Labs — Fri, 11 Sep 2026 14:17:10 +0000

I have a complicated relationship with to-do apps.

I love trying them.

I love reading about productivity systems.

I love seeing beautifully designed task lists, calendars, tags, projects, priorities, integrations, dashboards, and all the other things that promise to help me become more organized.

But eventually, something always bothered me.

The task manager itself started becoming a task.

Create an account.

Create a project.

Create a list.

Choose a workflow.

Configure your settings.

Connect your calendar.

Learn how everything works.

And then, finally, add the thing you actually wanted to remember.

At some point I thought:

What if a task manager just let me manage my tasks?

So I built one.

It's called Wumilo.

Your tasks. Your focus. Your phone.

Wumilo is an Android task manager built around a fairly simple idea:

A productivity app should help you finish things, not give you another system to maintain.

When you open Wumilo, you can start typing immediately.

No account setup.

No onboarding questionnaire.

No complicated workspace configuration.

Just add a task.

For example:

Call Mom tomorrow at 3pm

Instead of making you fill out several fields, Wumilo can understand the task and turn it into something with the appropriate date and time.

You can also add tasks using your voice.

The goal isn't to make task management smarter for the sake of being smarter.

It's to make getting something out of your head and into your task list feel almost effortless.

I Didn't Want to Build Another Productivity System

There are already countless excellent task managers.

Some are incredibly powerful.

Some are designed around projects.

Some are built around calendars.

Some are designed for teams.

Some give you an almost unlimited number of ways to organize your life.

That's great.

But I wanted to build something different.

The question I kept coming back to was:

What is the minimum amount of friction between thinking about something and getting it into your task list?

That's the experience I wanted to optimize.

Of course, Wumilo still has the features you'd expect from a proper task manager:

Subtasks
Notes
Priorities
Categories
Reminders
Recurring tasks
Widgets
Voice input
Progress tracking

But features shouldn't become the experience.

The basic interaction should still be:

Open the app → add the task → get on with your day.

Focus Mode

One of the features I care about most is Focus Mode.

A normal task list can quickly become overwhelming.

You open the app and see twenty things.

Then thirty.

Then fifty.

Everything feels important because everything is sitting there looking at you.

So instead of constantly showing the entire backlog, Focus Mode tries to answer a much simpler question:

What should I finish right now?

It puts one important task in focus instead of asking you to mentally process your entire list.

It's a small change, but I think there's something important about it.

A task manager shouldn't only help you remember what you need to do.

It should also help you decide what deserves your attention right now.

Privacy Wasn't an Afterthought

Another thing I wanted from the beginning was privacy.

A task list can contain surprisingly personal information.

Things you need to remember.

People you need to call.

Bills you need to pay.

Appointments.

Ideas.

Work.

Personal plans.

I kept asking myself:

Does this data actually need to leave the phone?

If the answer is no, why should it?

Wumilo is designed to work without requiring an account or cloud service just to manage your tasks.

Your task manager should feel like something that belongs to you and your phone, rather than another service you have to maintain.

Reminders Are More Complicated Than They Look

This was one of the biggest surprises for me.

A reminder sounds simple.

You create a task.

You choose a time.

The phone reminds you.

Easy, right?

Not quite.

On Android, reminders can involve alarms, permissions, notifications, battery optimization, manufacturer-specific behavior, Android version differences, and operating-system decisions that can affect how reliably something fires.

Then you start testing on actual devices.

And suddenly, something that seemed like a tiny feature becomes an entire engineering problem.

I've had users report reminders arriving late or behaving differently on their particular devices.

That's when you realize that building an app isn't just about making something work on your phone.

It's about making it work on someone else's phone too.

Building for Real Devices Changes Everything

One of the biggest lessons I've learned building Wumilo is:

You don't really know how your app behaves until other people use it.

An emulator can only tell you so much.

Your own phone can only tell you so much.

Automated tests can verify specific behavior.

But real users will find things you never expected.

Different manufacturers have different battery-management systems.

Different Android versions behave differently.

Different settings affect notifications.

Some devices aggressively optimize battery usage.

Others handle background work differently.

And sometimes someone sends you a message saying:

"The reminder didn't fire."

Now you're investigating Android alarms at midnight.

That's indie development.

You build something because you think you've covered everything.

Then someone with a completely different device shows you the thing you missed.

And honestly, that's one of the most useful parts of the process.

Small Feedback Can Change Big Things

One of my favorite parts of building Wumilo has been talking directly with users.

Because I'm an indie developer, feedback doesn't have to pass through a product manager, a support department, an analytics dashboard, and three meetings before reaching me.

Someone can simply tell me:

"I think this would be better if..."

And I can actually think about it.

Some of the improvements I'm working on come directly from these conversations.

Better snooze options.

Clearer reminder indicators.

Better recurring-task interactions.

Small changes to make certain screens feel less awkward.

None of these necessarily sound like huge features.

But when you're building an app used every day, those little details matter.

A product can technically work and still feel slightly annoying.

Those tiny moments of friction are often where the best improvements are hiding.

Why Android?

I chose to build Wumilo for Android partly because Android gives you a lot of room to build experiences that feel integrated with the phone.

Widgets.

Notifications.

Alarms.

Voice input.

Quick interactions.

Different screen sizes.

Different device configurations.

There's also a lot of complexity.

That's part of what makes it interesting.

I like the challenge of making an app feel like it belongs on the device rather than simply being a website placed inside an app.

A task manager is something you might open dozens of times.

It should feel fast.

It should feel familiar.

It should get out of your way.

I'm Building Wumilo as an Indie Developer

Wumilo isn't being built by a huge product team.

It's something I started because I wanted a task manager that worked the way I wanted.

That also means development isn't always perfectly predictable.

Sometimes I have a lot of time to work on it.

Sometimes I don't.

Sometimes an update takes longer than expected.

And sometimes a feature I really want has to wait.

One question helps me make those decisions:

Would this make the app better for someone who just wants to get things done?

Sometimes the answer is yes.

Sometimes the answer is:

"That's a cool feature, but it doesn't belong here."

And saying no to features can be much harder than building them.

Especially when you're the developer, designer, product manager, tester, and user all at the same time.

There Is Still a Lot to Improve

Wumilo is nowhere near finished.

I don't think a productivity app ever really is.

There are still things I want to improve around reminders, Focus Mode, widgets, recurring tasks, and the general experience of managing tasks throughout the day.

And I'm sure users will find things I haven't even thought about yet.

That's actually something I'm looking forward to.

When someone says:

"This part feels weird."

That's useful feedback.

It points to something that might not show up in analytics.

There is a big difference between an app that works and an app that feels good to use.

Usually, that difference isn't one giant feature.

It's dozens of tiny details.

The Bigger Idea

I didn't build Wumilo because I thought the world desperately needed another to-do app.

There are already plenty of them.

I built it because I think productivity software can sometimes forget what it's supposed to accomplish.

The goal isn't to build the perfect task-management system.

The goal isn't to have the most features.

The goal isn't to spend an hour organizing your productivity system every Sunday.

The goal is much simpler.

Remember what matters.

Decide what to do next.

And then actually do it.

That's what I'm trying to build with Wumilo.

Your tasks. Your focus. Your phone.