Show HN: I built a tool to get "Your app was approved/rejected " alerts on Slack
statused.com
Works for Android and iOS workflows, currently.
Looking for feedback, suggestions, and maybe opportunities I'm not seeing?
statused.com
Looking for feedback, suggestions, and maybe opportunities I'm not seeing?
Not sure digging up your Slack, Google, Apple API keys is faster...and probably also more of a hassle for compliance than just using Slack and Email which are already there.
Ah, ok. That's the part I missed.
I would still be a bit worried about the security of it all if this were a big company though, but it's maybe doable for smaller ones?
Although the future of Statused holds more than just forwarding emails to Slack. I intend to add support to other "channels", such as Teams, Discord and Telegram, as well as other types of integrations such as incoming webhooks, so a status update could directly trigger a custom action in your CI/CD pipeline, for example "detect the app has finished processing, then submit it for review".
On top of that, I don't think you get those emails for every Google Play changes that are made to your release, so not sure if that would work. Again, this might work, but I'm really not sure.
You have a point with those concerns about sharing API keys. But this has become pretty standard and devs share those keys with a bunch of services already, such as as with CI systems, app store user review services, sometimes ASO monitoring tools even.
The FAQ page highlights which permissions the API keys need: https://statused.com/faq#which-permissions-does-my-google-pl...
Thanks for raising these points! It's valuable feedback to understand how people perceive this product!
Maybe add some more signals to get a real value for the customer, like a real mail-filter, RSS and other newsfeeds (which is popular here) or some dozen more APIs.
I agree with your points. The point of gathering the API key is to actually be able to provide a lot more information in the future, such as some light data science (analytics) into your releases, and maybe expand to other areas (e.g. taking actions from the Slack messages themselves).
What do you mean with "like a real mail-filter"?
The RSS feature is kinda on the roadmap but I haven't gotten any feedback about users wanting that type of integration. Incoming webhooks is higher up in the list, so users can trigger internal CI actions upon receiving requests to such webhooks.
Any other type of APIs you'd like to see this tool covering? :)
I mean receive mails from a mail-server (pop3, IMAP, Gmail, exchange, etc.), filter according to user-specific criteria and output on slack. This might even give some additional value by having maintained filters, if you can get your hand on enough for your customer's relevant mails. And it would give opportunity to shrink the privacy-problem, as people could use dedicated mailboxes for such mails.
And you could even reuse the filters+interface for all other sources too. Like maybe, they only want to see certain releases, or for a specific app.
> Any other type of APIs you'd like to see this tool covering? :)
That's a problematic question. There are too many apps and APIs. You could focus on the common tools, like issue-trackers (Jira, etc.), error-trackers (sentry, etc.), maybe Slack itself? But instead of just adding APIs, the actual value for your customers might be to add unique use cases which pushes your tool above the existing workflows. Adding statistic and appeal to rejections seems worthful on surface. But you should be aware that you are competing with others tools, like Zappier or a simple mail-clients, and you likely have not enough manpower to beat them on their ground. So you may better focus on quality and additional value for your customers, and communicate this very very well.
I built a similar open-source thing a few months ago which pulls in a lot more information and you can even control things on the store through Slack commands: https://appstoreslackbot.com
Currently, it only works for iOS and is pull-based.
How many users are using that service? How come you decided to make it 100% free?
Your website is beautiful btw! I thought about building my tool as a Slack bot but thought that then it would be too limited to only Slack. I intend to add other types of workflows in the future, such as webhooks (to trigger special workflows in your CI) and a RSS feed :)
I'd love to connect with you if you wanna work together on something! t.me/rogerluan
We built this in about a week as it mostly piggybacks on a critical piece of infrastructure behind https://www.tramline.app, and hence kind of runs by itself.
So we didn't really care for adding pricing to it. Tramline is what we _really_ build :)
The service itself just currently happens to respond primarily as a Slackbot, but that's just an implementation detail and can be tweaked.
Would love to connect, let me ping you on telegram!
The cool thing is that I don't intend to take it down now that I built a SaaS around it. I'll keep both open source and SaaS versions of it live, and try to upsell the service to those who don't feel like self-hosting it. Plus, the SaaS version comes with features not available in the open source version (such as support to Android) :)
Thanks for spotting and sharing this!
Edit: Some quick feedback. Your pricing uses the word "workflow" but what that means isn't described anywhere on the site or FAQ. I assume it's used once you create an account but it's not clear what it means before signup.
I'll fix that right away.
PS: Lemme know if you need any guidance setting things up or have any further questions! There's the official support email but also white-glove treatment at t.me/rogerluan ;)
You'll notice that the subscription is based on workflows. A workflow is a connection between a source (e.g., your iOS app) and a destination (e.g., a Slack channel). You can set up as many workflows as you'd like, which is a great way to separate different types of notifications. For instance, #ios-deploys-prod receives updates about your production app, #ios-deploys-staging receives updates about your staging builds, and #android-deploys-beta receives updates about the Beta track of your Android builds. Each of these is a separate workflow.
Now you can find all this in the FAQ: https://statused.com/faq#what-are-workflows
Great spotting, thanks once again!
What would you suggest instead? I thought "No more 'Is the app live yet?'" would be clear enough, but I guess not
> When you submit a new build to one of the tracks (internal, alpha, beta, or production), they go through different statuses, e.g. “In Progress”, “Completed”, “Halted”, etc. Each of these will send a new notification to your team.
I plan to add phased rollout user distribution too, so your team gets an update when the app rolls out to e.g. 5% of your users → 15% → 50%, etc…
If slack app are you talking about workspace approval?
Key features:
- Real-time Slack notifications for iOS and Android app review statuses. - Instant alerts for TestFlight releases for your internal team and external testers. - Updates on app processing changes, all in one place. - there's more, but those are the main features
Happy to answer any other questions you might have! I wonder if the landing page isn't clear enough; is there anything you'd improve on it?
The SaaS took 270 hours so far (so if I had done this in a typical 9-5 schedule, that would've taken me ~6-7 weeks). Sounds like too long, and it is, but considering I knew nothing about BE, FE, db, infrastructure, etc., and that I built it from scratch, completely ditching the previous version I had, it was quite a fun journey!
AMA :) happy to answer any other question
Using the words of one of the customers I have: "it shifts the paradigm from us needing to pull information to getting it pushed to us! Really helpful!"
It frees up time of mobile developers' and democratizes the access to the information across different departments :)
Lemme know if there are other questions I can help answering! Happy to explain anything in further details
They just run in a sandbox.