4 ms·

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 scra

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.

LyndsySimon 7y ago
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... The risk here seems small.
- alttab 7y ago
  The risk isn't small compared to the value add, especially if all they are doing is providing an abstraction layer that isn't "too hard." The value seems to be free hosting for the polling and scheduling. This isn't too different than IFTTT abstraction-wise, and is easily reproducible in AWS using data pipelines and lambdas. Why take an external dependency if what they are doing is rather simple? I'd argue you are right about the complexity. The hook of the service seems to be easy integration and lack of infrastructure requirements. At scale, a freemium model won't work. But it would provide initial traction for small use cases. This can be funded for a while without major rounds. The advice to monetize now versus building community and getting users / crowd sourcing plugins is solid if the aim isn't to open source it.
codezero 7y ago
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.
- edoceo 7y ago
  I think the point is: monitize now to reduce risk
  - codezero 7y ago
    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.
    - edoceo 7y ago
      $1/trigger/mo. 30 days. No refund if services were delivered, if I pre-paid then pro-rated refund. No expectation of portability.
- michaelbuckbee 7y ago
  I would feel much better paying them money for this than hoping it's free forever.
- andyburke 7y ago
  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.
  - codezero 7y ago
    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.

LyndsySimon 7y ago

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... The risk here seems small.

alttab 7y ago
The risk isn't small compared to the value add, especially if all they are doing is providing an abstraction layer that isn't "too hard." The value seems to be free hosting for the polling and scheduling. This isn't too different than IFTTT abstraction-wise, and is easily reproducible in AWS using data pipelines and lambdas. Why take an external dependency if what they are doing is rather simple? I'd argue you are right about the complexity. The hook of the service seems to be easy integration and lack of infrastructure requirements. At scale, a freemium model won't work. But it would provide initial traction for small use cases. This can be funded for a while without major rounds. The advice to monetize now versus building community and getting users / crowd sourcing plugins is solid if the aim isn't to open source it.

codezero 7y ago

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.

edoceo 7y ago
I think the point is: monitize now to reduce risk
- codezero 7y ago
  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.
  - edoceo 7y ago
    $1/trigger/mo. 30 days. No refund if services were delivered, if I pre-paid then pro-rated refund. No expectation of portability.
michaelbuckbee 7y ago
I would feel much better paying them money for this than hoping it's free forever.
andyburke 7y ago
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.
- codezero 7y ago
  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.