I've been helping with a small portfolio of Slack apps under the brand https://happybara.io, including Nightowl (multi-DM broadcast for Slack, like BCC for email), and Channitor (channel management & auto-archiving).
It's been a really interesting journey making mistakes & learning from them.
One mistake that made me feel foolish:
I assumed no one would ever pay for one of the apps. A paywall was added "just in case" -> boom, customers almost immediately started signing up. I felt incredibly silly after that, especially for the number of times I've read on HN and similar sites "your work is valuable" and "charge more".
This is cool! I looked into building a slack app myself, I'm curious: how are you liking the slack store and its policies? Was starting out difficult? I vaguely remember having to have your app installed in multiple workspaces already before being listed in the store
This is neat, I appreciate that even if I can't use the service, i still learned something new about what's possible. Gonna keep it in the back-pocket for sharing with friends.
Also reminded me of when Justin Jackson talked about how he hired his kids for help with real projects and the positives from it https://justinjackson.ca/flipping-tables
if you want to get started writing super quick, you can also take a look at some of the super minimalist platforms that are basically as you describe - like https://bearblog.dev/ and https://mataroa.blog/.
I've stumbled on both from submissions to HN and they have become my recommendations for friends that want to write, especially the couple who are prone to jumping down technical rabbit holes & not ever getting to the writing.
> Bear Blog has been built as a platform and not as an individual blog generator. It is more like Substack than Hugo. Due to this it isn't possible to individually self-host a Bear Blog.
Guessing the other is similar.
To be honest a single HTML file which is what I'm thinking of, I can grab a shared server from any of the old school hosting providers ans upload an HTML page... Or deploy staight to cloudflare/gcp/azure/aws just as easily.
Sure for some people that is a lot of work but I do a lot of devops/infra work and it will take me more time to write the HTML page than to deploy it on the web with SSL... To put it into perspective I already have a VPS with nginx infront if it...
I see resolutions for protecting against the now-known error modes discussed, and better alerting to get the on-call engineer (aka always Zeke :D) looking into things quicker, but curious how they might approach preparing for "unknown-unknowns" that will come in the future.
Are there good ways for a small-team to proactively stress test a system without mucking up customers? Open question.
Video[0] isn't a direct answer, but I found it helpful for understanding the trade offs that come when considering using electric power for a plane vs regular fuel. They show the math in an easy to follow diagram.
tl;dr for their small kit aircraft the weight of batteries they would need to match the stored energy of equivalent fuel (even with a battery at 500wh/kg) would be 5-10x heavier, and also not get lighter during the flight. They said for long range it doesn't make sense, but that there are lots of companies iterating in the short range electric space.
- Product Hunt began as a simple list emailed out to people.
- Levels.fyi was powered by a Google Sheet until 2021.
- Crave Cookies was making $200k/mon according to their interview using a SQlite DB which started as a JSON file.
- Headlime started as a JSON file sitting on his frontend with no DB - then sold for $60k a week later
Tools I personally am exploring:
- DB: Google Sheets - either through API (numerous services like sheet.best for this or self-hosted)
- DB: Airtable - it provides API out of the box and has forms and whatnot too, keeps things real quick to start
- Whole Shebang: have only built toy examples, but Glideapps and Softr seem like handy options to spin an idea up really quickly and not getting distracted by tech rabbit holes
Interested to see where this goes in the future. I know a lot of technical people who are still wary of the command line, and I have yet to find a resource which is approachable enough to share widely.
This is the first post in a series that will walk through App Home design and best practices for Slack apps, step by step. We want to help developers create awesome apps which leverage all the capability available from Slack, and we'd love to hear ideas & examples of other apps you think do a great job.
Streamly is a task management tool that meets your company where they are - in Slack. With customizable request workflows, private channels for teams to triage inbound work, and syncing to your team's existing task management tools like Asana, we hope Streamly simplifies your team's efforts and helps them concentrate on the important stuff. Also we couldn't help ourselves, so Stream -> Otter mascot.
It's free for one Stream (request workflow), so give it a shot and let us know what you think! If you need any help just click the 'Help' button. We'll respond right in Slack as if you were getting help from your team, no need to go find our support email.
It's been a really interesting journey making mistakes & learning from them. One mistake that made me feel foolish: I assumed no one would ever pay for one of the apps. A paywall was added "just in case" -> boom, customers almost immediately started signing up. I felt incredibly silly after that, especially for the number of times I've read on HN and similar sites "your work is valuable" and "charge more".