Building Happy Stack: notifications

The plan has always been to launch Happy Stack with email notifications; that’s it. I have lots of other notification channels planned of course, but email is still the most universal.

For the most part, this focus on a single notification channel has made my life a lot easier. It keeps the UI simple, and the development straightforward. There was one thing bothering me, though: was I making life really difficult for future me?

After mulling it over, I decided a compromise was in order. Behind the scenes, Happy Stack now supports any number of notification channels for both the agency (the Happy Stack user), and the project client. Email, SMS, Slack, Telegram—pretty much anything that Laravel supports.

As far as the Happy Stack users are concerned, though, email remains the only option.

There are two benefits to this approach:

1. It makes it much easier for me to add new notification channels without a big code or database refactor. I’m still at the point where I can run artisan migrate:fresh, so now is the best time to make these changes.
2. It allows me to ignore the tricky UI problems associated with supporting multiple notification channels.

The second point is particularly important, given the limited time I have available before launch. Something as apparently straightforward as a Slack integration involves all manner of tricky UI decisions. Should Slack accounts be configured at the Team level, or the Project level? Either way, when and where do you configure your Slack integration? The list goes on.

Focusing on email notifications allow me to sidestep all of these difficult choices, and get something launched. There’ll be plenty of time for UI noodling later.

Next week I’ll be wrapping up notifications, and adding support for additional services.