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
I can’t believe its not @twcau@simonbs Happy to. Will give it a bash with some Uptime Kuma status messages via webhooks for starters.
@simonbs But first... command line:
PS C:\Users\pc> curl -X POST https://api.brrr.now/v1/br_usr_<redacted> \ -d 'Hello world!'
{"success":true}curl: (3) URL rejected: Bad hostname
PS C:\Users\pc>
Message was delivered successfully to target device (testing from Australia, executed from a Win11 device running a PowerShell terminal).
Possibly my network or firewall causing that URL rejected message in the curl response - will need to look when I have some time.
@twcau Hmm. Haven’t seen that before 🤔
@simonbs Also, interesting item when adding the Webhook to Uptime Kuma, and sending a test message from it (see screenshot below).
Again, not sure if you, or me and my firewall/adblocking services causing it without further investigation.
My Uptime Kuma instance is running as a Home Assistant app (some kind of quasi-Docker container I think). At some point, will migrate it to a standalone Docker container.
@twcau Hmm.. I wonder why it would disallow that certificate.
@simonbs Just confirmed - It tripped a Firewall rule at my end. Cloudflare has the domain classified as Parked domain (which I block), and the rule triggers line up with my test times.
I’ve just submitted a request to CF to have the parked classification removed, and switched to API.
@twcau Interesting! Thanks a lot for looking into this! I've no clue why Cloudflare would register it as parked. I even use them as DNS.
@simonbs Getting back to core, happy to report that I can't find any issues so far. Tested the core JSON body options.
Only possible thing I could find is how line breaks behave in the messages. I found that if I wanted part of the text in message: to appear on a new line, I needed to use \r\n, and not just \n alone.
Also no issue found using any combination of JSON fields regardless of order.
@twcau Thanks for testing so thoroughly! I’ll make sure that \n works.