Two weeks ago we launched Pipedream in beta and it has been great to see the response. In particular, one customer emailed us and said, “Wow! This is definitively the fastest way to run a script on a schedule!”
When you launch a new product it is tempting to list a laundry list of features that you think can address every potential use case. However, it is often better to have a simple value proposition that every developer can understand, relate to and benefit from.
So, now when people ask me what Pipedream is, my shortcut answer is to say it’s the fastest way to run a script on a schedule. If they engage, I have an opportunity to share all the other integration capabilities, features and benefits.
As always, we think there’s a lot we can improve and are eager for feedback. Also, if you want a specific app or API fully integrated, let us know. You can reach us here or on Github [1], Twitter [2] or Slack [3].
If you do not need enterprise use cases (single sign-on, higher level SLAs, shared authentication, etc) and your scale fits within our defined constraints, then free is the price.
to me that translates as "WARNING! TRAP!" because I may decide I like your thing, and then my users may decide they like _my_ thing, and then suddenly I find out what your price is for my scale and "oh shit! I'm going to go broke OR have to recode everything"
ESPECIALLY since this would become a key part of the infrastructure / how my app gets its stuff done. Replacing your service with a competitor or something homebrew would be a major pain, especially when I find myself unexpectedly popular.
there is NO WAY I would ever use or recommend a service that refuses to tell me what my potential long term costs are up front.
It's too much of a gamble with a business or worse, a hobby project that isn't making me any money to compensate for this unexpected "balloon payment".
Vendors that are aiming at a split workflow, with a free tier and a paid tier usually have some set paid tiers and then a “contact us” for beyond that. For example, Slack gives you prices for the Standard and Support plans, and then lets enterprises contact them for negotiating prices. The problem with Pipedream is that non-enterprise customers will want to use their so-called enterprise plan.
Haggy - we have no plans to charge individual developers for low volume workflows that fit within our defined constraints. Our revenue efforts will be focused on enterprise use cases.
I have no desire to be hand-savvy so please ask whatever questions you have and I will do my best to clarify.
Hi, this is Dylan, another co-founder and engineer. I'm sorry we dropped the ball here. As you can imagine, it's tough to respond to every request and we've been a bit busy since launch, but I apologize we didn't get to yours.
All of us were early employees of BrightRoll [1], an advertising marketplace that handled 10 million requests / second at peak. We've scaled large systems in the past and we've built this system with scale in mind.
Believe it or not, most workflows are extremely low volume. That, in part with the design of the system, allows us to offer the generous free tier.
We're planning to introduce paid tiers soon. You can see my comment on the parent thread that addresses some of the general questions around pricing asked by others in the thread.
This was a very early release of the platform and we hoped offering the product for free would encourage experimentation. To a great degree, we've seen that, so we think it was the right choice.
We believe anyone should be able to run simple, low-volume workflows at no cost, sharing their workflows with the public so everyone benefits from the work of others. We also want to foster a positive community where people feel good about sharing their work and where everyone can learn from one another.
In the future, we may offer features available on paid tiers which would be logical enterprise features such as single sign on (SSO), team collaboration and higher SLAs and throughput.
We believe anyone should be able to run simple, low-volume workflows at no cost, sharing their workflows with the public so everyone benefits from the work of others. We also want to foster a positive community where people feel good about sharing their work and where everyone can learn from one another.
In the future, we may offer features available on paid tiers which would be logical enterprise features such as single sign on (SSO), team collaboration and higher SLAs and throughput.
Thanks for your reply! But it doesn't answer my question: I'm worried about how you will sustain your platform in the long run for all those free tier users.
Learning a new tool -even if it's friendly and has a community around it- takes time and effort. We want to know it will be there in the future. That's why I'm interested to know: how are you planning to keep Pipedream alive for, let's say, the next 5 years?
Co-founder here. We have been heads down working Pipedream for the past 9 months and are excited to share our beta with you.
Pipedream is an integration platform built for developers. Develop any workflow, based on any trigger with authentication management built-in and no server or cloud resources to manage.
Workflows are code, which you can run for free.
The beta version includes the ability to:
- Run any Node code, or use pre-built actions
- Trigger workflows via HTTP, Cron, integrated apps or email
- Create, share, and fork workflows from the community and
- Send data to S3, Snowflake, email, SSE, and more.
Coming soon — Develop locally and deploy workflows via CLI, SDK, and more.
We think there’s a lot we can improve and are eager for feedback so please send us your ideas and opinions. Also, if you want a specific app or API fully integrated, let us know.
We believe anyone should be able to run simple, low-volume workflows at no cost, sharing their workflows with the public so everyone benefits from the work of others. We also want to foster a positive community where people feel good about sharing their work and where everyone can learn from one another.
In the future, we may offer features available on paid tiers which would be logical enterprise features such as single sign on (SSO), team collaboration and higher SLAs and throughput.
So basically, people are going to build on top of your service and if yall don't figure out a revenue model, you'll need to close down shop, leaving people scrambling to migrate somewhere else...
No thanks, I've been there before. You'd be better off just charging from the get-go. Otherwise, this should be 100% open source.
From your past experience, do you have anything constructive to tell this new team on how they can attempt to build a business without knowing the future that would make you more comfortable using it?
I ask because I see a lot of these dismissive comments on HN which end with "open source it" - and that doesn't seem like a super constructive piece of advice to a new startup team.
FWIW, at my current company, an analytics company, about five years ago, we made it clear that no matter what data we collected, if you leave the service or we shut down, we will get you all that data to take with you in a very reasonable format.
It's always risky to invest in a new service, but sometimes risks bring great rewards, and I think it's helpful if you're giving input, to try to make it constructive.
Build a cost model.
Set prices that would make them profitable based on that model.
Offer the service at that price.
See if people are willing to pay for it.
Verify that costs and profitability match the model.
If the model turns out to be inaccurate:
A) Change the architecture to reduce costs to the point where it becomes profitable at an attractive price point for customers, or
B) Move on to the next idea.
It's not that complex, and more startups should be more realistic about profitability.
I feel like there's too much focus on the price here, and the thing I am concerned with is that the original comment was about how services shut down and they didn't want to invest in the unknown. Paying for that seems doubly risky to me.
That said, I get your point that if you can create a model that gives you a good sense of future profitability, you are in a better position not to die as a company.
Start charging immediately, and put up a real pricing page with SLAs. Find out as soon as possible if people will actually value this enough to pay for it.
This provides a signaling of value, creates a real business relationship, and directly contributes to the lifespan of the vendor.
It doesn't have to be right from the get go. Hard is why it should get done.
A free model doesn't really tell their business if there's actually demand and if people actually value it when supply is "infinite" when in reality it isn't.
Guess a high price with some research for similar things and lower it iteratively. Def. see what sticks.
They could go the AWS route, start high and decrease prices.
Also they could combine this with discounts, such as if someone preallocates capacity for X month, they get f(X) % discount.
They should build a core customer base. Solicit feedback about what niche feature they would happily pay for.
For example here's a GitLab issue that I think people would (might?) use: https://gitlab.com/gitlab-org/gitlab/issues/15536 (provide a "lock service" or a queue with max concurrency gate and launch pipelines / jobs)
People are often a lot more upset when they pay money and there is no exit plan. Shut downs can be abrupt and chaotic, suggesting they monetize immediately doesn't seem helpful either. If that's the suggestion, I'd ask: how much would you pay and how long do you expect notification in advance of a shut down? Do you expect a refund? Full or partial? Do you expect portability? If so, what kind.
The workflows are Node.js code. If you need to transition away, building an abstraction layer for the stuff they provide that you use shouldn’t be too hard. It would be even cooler if they committed to open sourcing their implementation if they discontinue the service...
Thanks for the response! I wasn't trying to rain on your parade, but having a reasonable revenue model in place does help give some confidence that 1) you're going to be around a while and 2) you're not selling data I don't want you to sell.
Forgive me if this is clean and I haven’t seen it I’m just browsing from a mobile device.
With all workflow type services I’ve encountered I find that the actual underlying workflow can’t be managed under source control as one would do with (hopefully) most if not all application & infrastructure code.
Deploying workflows from source via CLI or your CI/CD pipeline is in the works! We want you to host workflows on Github / Gitlab and be able to deploy them using your standard process.
Feel free to reach out to me directly if you'd like more information and I can let you know when we're testing this.
Speaking of which, it's always overwhelming learning new tools. I know I can benefit from this, but at the same time I'm not sure I can risk trying it out given the time it will take to experiment and learn. I'd be using triggers based off Github commits and merges, but I don't see any specific examples for that and it's not exactly clear how the tutorial on the home page would translate to what I want to do so I currently feel deterred from giving it a whirl. Are there plans to create more tutorials? What kind of (rough) timeline can we expect to see more tutorials?
I completely empathize with the time involved learning new tools. I'm happy to create a tutorial specific to your use case. We've built a few workflows to process Github events and I'd love to show you how this works end-to-end.
Is there anything specific you'd like to do with the commit / merge events, just so I make sure the tutorial targets your use case?
Feel free to reach out directly if you'd like to talk more at dylan [at] pipedream [dot] com.
Thanks for the response and involvement in this thread, it really shows how committed you guys are to providing a great user experience.
The specific use-case I have in mind is that when a commit made I'd want to run various checks on configuration files in the repo to make sure specific conventions are followed and that certain file references exist. Upon a merge I'd like run a build process and send the build files to Heroku, Digital Ocean, or AWS.
The easiest way to run code in response to Github events is using Github's built-in webhooks for a repo. I made a video showing you how to set that up to forward events from your repo (e.g. every time you merge a branch to master), then run code on Pipedream in response:
and press the Fork button in the top right to create a copy of it in your own account. You can modify that copy and run it for free.
The video isn't perfectly polished and I made a few mistakes, but we've built Pipedream to make it easy to debug your workflows, too, so I hope the mistakes help you understand part of its power!
A couple of notes on your specific use case:
* There's no webhook event for new commits. A PR (like I show in the video) or a push might be the best event to listen for. You can then run Node code to list commits associated with that push. See the API docs for commits here: https://developer.github.com/v3/repos/commits/ .
* I wasn't sure specifically what build process you wanted to run, so I end the video reviewing how to add new steps to the workflow and walk through a few options: you can run any Node.js code or any of our pre-built actions. You have access to the /tmp dir on Pipedream and can use a package like child_process [1] to spawn some commands if you need to run anything on the shell. Unfortunately you don't have access to a full shell but let me know if what we provide works or doesn't — we'd love the feedback.
Let me know if that helps or if you have any questions!
You can program Amazon SWF in Python with boto library.
Example: http://boto.cloudhackers.com/en/latest/swf_tut.html
As such you can manage this under source control.
I assume similar projects exist for another cloud providers and languages.
Haha, damn nice job. I actually thought about this 1 yr ago and started working on something very similar, though it was more interactive. Even started an LLC and got a good prototype, but didn't have the time to work on it.
Great work! This is incredibly useful stuff and can't wait to start trying it out
This looks pretty awesome, even at this stage. I’d love the ability to write workflows in other languages (particularly Python), but understand that this seems pretty early-stage at this point and that might already be on the roadmap.
Out of curiosity, are you hiring? I’d be interested in hearing what your longer-term plans are and am looking for something new. This seems right up my alley.
ETA: I see from the article that Python is indeed coming. I’d love to be a part of that!
Just wanted to follow up to let you know we're starting work on Python soon. Feel free to subscribe to the issue here to get notified of our progress: https://github.com/PipedreamHQ/roadmap/issues/1 .
Sounds like a tool for devops. As a developer I would rather do extra work but on a mainstream cloud using a favourite language. Then again I am not in start-ups.
Thanks for the comment and we agree with the need for custom responses. We are working on a more advanced tool than RequestBin to solve this use case and hope to share it more broadly soon. We have been bombarded with webhook calls and intelligently handle throttling if necessary today.
