Yesterday evening I threw together a landing page for a side project to my other side projects:
It’s a tiny and opinionated tool for sending push notifications. No sign up. No message history. No dashboard.
I like it. Would you? 😄
Yesterday evening I threw together a landing page for a side project to my other side projects:
It’s a tiny and opinionated tool for sending push notifications. No sign up. No message history. No dashboard.
I like it. Would you? 😄
If I am to release brrr, then I’ll need to come up with a pricing strategy. Even if it’s a simple app, I’ll need to ensure that I cover my costs and ideally earn just a little. Choosing a strategy is difficult, though.
Current ideas include:
- First N pushes are free, then $X for 1,000 pushes.
- First month is free, then $X/year.
- One device is free. $X/year for multiple devices.
A tip jar and one-time purchase seem risky for an app with hosting costs.
When people try to send pushes without an active subscription, I could just return an error, but I feel like I should also do something more fun.
Like, I could send a push saying people need to start a subscription or scramble the text in the notification.
But I fear that any such notification might be sufficient for some users to deduce why they would have otherwise received the notification 😄
Do you want to help me test brrr? 👇
https://testflight.apple.com/join/55qZ7dRn
Learn more about the project on https://brrr.now
brrr’s site has a little notification composer now. You can use it to send notifications to yourself.
It also shows the JSON and the cURL command that can be used to send the notification.
This is a super-duper early take on having Codex or Claude send a notification when it's waiting for input using brrr.
Try it if you're feeling adventurous. I hope to polish it over the next few days.
Brrr doesn’t store anything about your notifications. No history. No metadata. No analytics events.
It does, however, store a single counter. One integer. It increments every time a notification is sent. That’s it. No timestamps. No user info. Just a number that tells me the service is being used.
It’s not like there’s a MASSIVE load, but I have to admit, it has been pretty satisfying watching that number tick up over the weekend.
We just passed 1,500 notifications sent.
So many people are already asking for brrr to show historical notifications that I might need to find a way to support this.
It’ll have to be local, though, as I really don’t want to store the content of people’s notifications.
Notification support is so bad on macOS that I fear this will be a pain in the…
Huh, verifying Apple's JWS in a Cloudflare Worker is going to be tricky (see link). Maybe it's time I give RevenueCat a try?

Unrecognized or unimplemented EC curve \"id-ecPublicKey\" requested when use crypto with compatibility_flags = ["nodejs_compat_v2"] & wrangler v3.78.7. Here is the error source: https://github.com/...
I just really wanted to use Apple's new-ish SubscriptionStoreView in the app. I'm a fan of such a page being somewhat standardized, so I don't need RevenueCat's paywalls. I don't need their insights either.
https://developer.apple.com/documentation/storekit/subscriptionstoreview
Ultimately, I just need someone to verify a JWS for me. I could set up a separate service for this, but it gets unwieldy, and maybe I'm better off with RevenueCat then?
I spent some time this weekend thinking about how brrr can support a notification history, by far the most requested feature, without compromising simplicity, privacy, or cluttering the app.
This is what I came up with:
- Local only
- Automatically deleted
- Hidden behind an anonymous button
I think this fits quite well into brrr.
Recent Notifications is now available on TestFlight along worh brrr’s subscription page and a redesigned iPad and Mac app.
I don’t think it’ll be long until I can release this 🤗
Here’s a demo of brrr’s Focus.
You set up a filter in your Focus with a custom criterion, for example work. Any notification that includes this criterion in the JSON payload will be allowed through.
The notification history in the app is filtered to match the Focus too.
This way, you’re entirely in control of which notifications are allowed through.
I don’t use Focus much myself, so I’d love to hear from people who do whether something like this would work for them.
When sending your notification, you just set 'filter-criteria’ with the same value as defined in your Focus mode.
This is now documented here: https://brrr.now/docs/