Simon B. StøvringYesterday 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? 😄
brrr’s onboarding flow is virtually nonexistent because I don’t think it needs to be any more complicated than this.
brrr is so simple. Its killer feature is everything that’s not there.
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.
Honestly, I'm leaning towards the first month being free and then charging something like $6.99/year. No monthly option. It’s a pricing model that’s as simple as the app, and a price point where I think most people who’d use it won’t mind too much. Or so I hope.
A colleague convinced me that I needed to add an additional feature to brrr. Tapping a notification should show it in the app to prevent accidental taps and missing the notification.
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 😄
Maybe I should take a page out of Festivitas’ book and have people name a fair price, but this time use it for a subscription instead of a one-time IAP 🤔
Do you want to help me test brrr? 👇
https://testflight.apple.com/join/55qZ7dRn
Learn more about the project on https://brrr.now
Squashed a few bugs and did some improvements based on the amazing feedback I’ve already received. New builds coming later today or tomorrow. Thanks a lot for the reports, everyone. Keep ‘em coming 🫶
Sending your first push with brrr couldn’t be easier.
ROCKETS 🚀
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.
I've made some changes to brrr's backend over the weekend that should make the experience generally faster. In particular, the HTTP call to send a push notification should be much faster now.
A coworker just showed how he uses brrr to get a notification on his iPhone when Claude is waiting for his input using Claude's hooks. I'm wondering if I should provide a brrr CLI to cater to this use case 🤔
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?
🐛 Bug Report — Runtime APIs node:crypto 'Unrecognized or unimplemented EC curve "id-ecPublicKey" requested.' · Issue #2768 · cloudflare/workerd
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?
Spent a bit of time last evening making brrr feel more at home on the Mac without sacrificing too much of its personality. I think this is starting to feel like a good balance.
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 🤗
Starting to scope creep in brrr. I mean, do anyone even use Focus Filters?
Chris Deluca@simonbs Yes, I especially use a nighttime filter while sleeping. I don’t want brrr to make any sounds if a backup completes successfully. PROD down? Oh hell yeah.