No. An application generated here sends no email, no SMS and no push notification — and that is verifiable in the package you receive: not one of its declared dependencies is a messaging client, and the temporary password of a newly created account is shown ONCE on screen rather than mailed out. What it does instead is different, and often enough: it puts what is due in front of you the moment you open it — an overdue banner at the top of the lists concerned, a bell and a notifications page, a calendar view. And for the reminder that actually rings, it hands over to your own calendar: an “Add to calendar” button passes the deadline to your phone. If automatic sending is essential to you, the application's code is yours and a developer can add it — this page says what that involves.
What it does not send — and how to check for yourself
An application produced here is a Next.js and Prisma project whose dependency list is frozen and readable: twenty-two packages, four development tools, and not a single email, SMS or push client. Rendering, the database, maps, charts, Markdown are all there; sending is not. This is not an omission you discover in use, it is a line missing from a file you can open: the `package.json` travels inside the archive.
The detail that confirms it best lies elsewhere, and it speaks louder than a list: when an administrator creates an account for a colleague, the application displays the temporary password on screen, once, and never shows it again. A product able to send an email would have sent it — that is the first reflex of any multi-user software. Here the instruction is to copy it and pass it on yourself. The constraint shows up on the very first account created; it is not discovered six months later.
Why this absence is a choice rather than an oversight: sending an email is not one line of code. It takes an account with a sending provider, a domain authorised to send on your behalf, DNS records attesting to it, and someone to watch what bounces. An application shipped without all that would send messages that land in junk — which is worse than sending nothing, because you then believe the recipient was warned.
What it does instead: the deadline comes to you on opening
The principle is reversed: instead of reaching out to the user, the application puts what is due up front the moment they arrive. When an entity carries a due date — a job to carry out, an invoice to collect, a contract expiring, a dated task — the list concerned shows a banner at the top counting what is overdue, before the table and before the filters. The question “what do I have to deal with today?” gets its answer without anyone having to go looking for it.
Two more familiar surfaces sit alongside it. A bell in the header and a “Notifications” page gather the records to follow along with their current status — read from your own data, never from a log kept on the side. And where the trade calls for it, a calendar view shows events in their place — by day, by week or by month, month on opening — with a sorted list of upcoming deadlines below the grid. It is the same question asked twice, for those who read a list better than a calendar.
The limit is real and worth stating: all of this assumes someone opens the application. That is the right regime for a tool consulted every morning — a workshop schedule, a job book, a case tracker. It is the wrong regime for a rare, distant deadline of the “follow this client up in eleven months” kind, which you will not see unless you happen to log in that day.
The reminder that actually rings: go through your calendar
That is exactly the case the “Add to calendar” button handles. On the record sheet of an entry carrying a date, the application builds the standard event file every calendar knows how to read — the one that arrives attached to an invitation — and your device opens it. The event then joins your usual calendar, on your phone, in Outlook or in Google, and that is what will ring, with whatever reminder you have configured there.
The division of roles is clean, and that is what makes it robust: the application holds the business data, your calendar holds the reminder. It does not need to know what time you want to be warned, on which device, or whether you are on leave — your calendar already knows all that and does it better. The button only appears where it makes sense: on record sheets whose data genuinely carries a date.
The trade-off is honest: it is a gesture, not a subscription. You send ONE event at a time, at the moment you look at the sheet; the application pushes nothing by itself and does not keep your calendar up to date if the date changes afterwards. For a handful of deadlines that really matter, that is more than enough and depends on no third-party service. For a continuous flow of dozens of appointments a week, it is not the right tool, and it is better to know that up front.
If automatic sending is essential to you
Two paths exist, and they do not take the same effort. The first touches no code: every list carries an export button producing a CSV of the rows displayed — filtered exactly as you have just filtered them, not the whole table. The file opens straight into a spreadsheet, separator and encoding included, and feeds whichever tool already sends your emails. Filter “overdue”, export, mail-merge: a five-minute weekly routine that creates no new dependency.
The second path is yours in the literal sense: the application's code belongs to you, it can be retrieved as an archive or on a Git repository, and it is an ordinary Next.js and Prisma project. Adding email there is well-charted development work — wire up a sending provider, write the message, trigger the job. What costs is not the code: it is the sending domain to configure, the provider account, and someone watching the messages that bounce. An agency or a freelance developer does this routinely.
The advice that holds either way: first measure how many reminders you would genuinely send in a week. Many teams find that the overdue banner seen every morning covers ninety per cent of the need, and that the few remaining deadlines fit in a shared calendar. Automatic sending is infrastructure: it is justified when the volume justifies it, not as a matter of principle.