PawPal

A pet schedule fails in the small conflicts: two walks at the same time, a task that will not fit, a budget that is already gone. I built PawPal so the urgent tasks come first and a collision comes back as a warning.

The problem

A list of pet tasks pretends every one of them can happen. Walks overlap. A task is longer than the gap it was dropped into. The month’s budget is already spent and the list still offers another bag of food. The person it frustrates is the one doing the actual walks, who finds out about the overlap by being in two places.

I wanted the urgent tasks first, and a warning when two of them collide, instead of a crash or a silent double-book. It was worth it because the warning is the thing you can act on. A stack trace is not a schedule.

How I built it

Tasks, pets, and owners live in memory. I was not building an account system. I was building the ordering and the conflict check, and a database would have hidden both behind a query. High-priority tasks go first. Inside the same priority, shorter tasks go first, so a quick task is not stuck behind a long one of equal urgency.

A task can carry an optional time. Daily and weekly tasks get their next date from a timedelta, so a repeating walk has a next occurrence instead of a copy you maintain by hand. Conflicts come back as warnings, not exceptions: a budget overflow, a task that will not fit, overlapping times.

A Streamlit page sits on that. The test file has 18 tests, which is where the overlap, the fit, and the budget are pinned down. The page is how you see the warnings. The tests are why I trust the order.

Challenges and what I learned

The warnings are the product. A scheduler that crashes on a double-booked walk is less useful than one that names the overlap and keeps going. Priority-then-duration is a small rule, and it is the rule that decides which walk you are told to do first. I would rather defend that rule than a list that claims everything fits.