Show HN: Scriptable.run, make your product extendable by anyone.
scriptable.run
scriptable.run
I have no idea what your product does.
The example at the top of the docs pages still doesn't help me understand what your product does. It also doesn't work, it just returns: {"message":"access token is not valid for this request"}
I'm guessing that's because I need to get a valid access token to run the example? Well then you'd better say that, and tell me how to do it, or even better don't require it for your first example to work.
I tried going into the "Advanced Guide". It had a handy first link that linked me to "Hello world in scriptable". That sent me back to the first page of the docs, with the example that doesn't work. At this point, I'm stuck and out, sorry.
Apologies again for doing a poorly job of getting the message across. We're currently working on revamping our landing page, docs and general onboarding story.
And, since you target developers, add as much info as you have. Don't skip messy stuff like "how to authenticate" or similar.
Good luck!
I think in this case the landing page is lacking in technical details to the point where it’s hard to understand what the product actually is. I like the general idea of firecracker as a service and sandboxed code as a service though.
Even the webhook example doesn’t really show where scriptable fits in, I think what you’re trying to say is that the customer can write some code to integrate the product with their slack and then the service will call the customer’s code in a sandboxed environment which is how the customer can extend the product right?
Why isn't this in the first paragraph of the introduction on your website?
Something that would let people write out basic automation workflows to respond to events, similar to what Zapier or Salesforce offers to its users.
There are, of course, halting problem-style issues. I _think_ you could paper over some of that at the description level. But really you want the right kind of hooks into the actual system. A scripting tool that is just "oh but you just hit the API" is way less nice than bespoke components for your own system.
And with event systems you have the usual event propogation issues of accidentally causing a massive fan-out of events from some action and causing your sysetm to fall over.
But this is really something that someone could write out as a component for other systems and make a lot of business SaaS's automation floors way better.
You really do want to offer _something_ to users, though. The users that can write Javascript... well, Zapier lets you write Javascript. Hell, Google Cloud Platform lets you write Javascript in little script blobs, complete with Google Docs-level concurrency. This is a bit weak compared to that.
The idea being that any SaaS app could basically bolt it in and then add trigger events that match to their apps business events/entities and allow user to extend the core business logic with their own "Scripts".
https://apps.apple.com/us/app/scriptable/id1405459188
I use this to schedule notifications, create widgets (e.g. to show AQI from PurpleAir), and do quick text processing automation.
I think I'm missing where your product runs and who is running what and why they are running a curl command, and if I'd have to make changes in my application to support this.
A general conceptual diagram on your site would go a long way.
The issue: when I choose "yearly" subscription, the page still shows price per month. So you're about to charge me every month? Despite I chosen to pay yearly. And where's the "2 months free" if I end up paying monthly??
Your starter pack costs:
$79/m (in "yearly" subscription) - so $79*12 = $948
(or $79*10 ??? because of the "2 months free")
$99/m - so $99*12 = $1188
$1188 - $948 = $240 - so it's actually more than "2 months free".
It's super confusing and I leave immediately no matter how badly I just wanted to buy it.
You’re totally right. This is pretty much “Forge as a Service” for others to use in their products as well :) In fact, we propably wouldn’t have build it (again) if we could have used Forge. I’m glad we did though, as it suits us actually much better, e.g. by being completely deployless.
I really wish the devs of this new shiny the best with their endeavours ... but that wound still smarts!
Raised eyebrows is an understatement
Missing out-of-the-box security/sandboxing, the time it takes to deploy and (cold) startup time.
With Scriptable, you don't need to worry about any of that. And there’s nothing for you to provision or maintain apart from saving the user-provided scripts in your database.
If you are running multiple users on the same lambda, one could potentially read filesystem data that another saved, for example (if the lambda hasn't restarted).
You also probably want to make sure each user has individual compute limits, so one user can't execute 1000 scripts/second and DDOS other users.
There's probably a lot of little things to think through (that I have not).