Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Launch HN: Pelm (YC W22) – Plaid for Utilities

pelm.com

Post reply on HN
Print view View original

41–50 of 91 posts

Re: Launch HN: Pelm (YC W22) – Plaid for Utilities

#41

Post by ok_dad »

drewkim wrote: post #35
ok_dad wrote: post #34

How is this differentiated from UtilityAPI ( https://utilityapi.com/ ) or other similar products?

UtilityAPI and other products are built by energy companies, not tech companies. We've talked to developers who've used these platforms and they consistently mention an extremely poor developer experience; lack of clear documentation, difficulty in building integrations quickly, little to no support, etc. One example: we talked to a paying customer of UtilityAPI who asked for a specific feature, and UtilityAPI asked…

https://utilityapi.com/about

I think UtilityAPI was founded by "tech people" as well. I wonder if you have any specific examples or comparisons that would make me want to use your service over a well-established company?

I work in the energy industry, and while I would love to just try out your service for comparison, I don't have the time. Your site is very lacking in details.

Also, you said you know how to build a "really good developer experience" without "lack of clear documentation", but the most basic endpoint you have for collecting energy usage intervals (https://pelm.readme.io/reference/get_accounts-account-id-int...) does not have a good example for the data you return for a 200 response; I can't tell what the actual data will look like! You state it's tuples with `(timestamp, value)` but do not show an actual example with tuples in your docs. Compare that to UtilityAPI's docs for the same type of endpoint (https://utilityapi.com/docs/api/intervals) which have a very detailed example.

I would say you have some work to do, but good luck! I would love to see multiple good alternatives for collecting energy utility data.

Re: Launch HN: Pelm (YC W22) – Plaid for Utilities

#43

Post by kolanos »

dmitrygr wrote: post #30

We NEED to stop training users to give away passwords for account X to services that are not X. We NEED to! This is what enables phishing to work! It normalizes this! Please do not do this! Next time some old lady loses her life savings due to phishing, you'll know that in some small part plaid and this helped. They trained her that it is ok to provide her password to someone.

If utilities gave them any other way, I'm sure they'd be using it.

Re: Launch HN: Pelm (YC W22) – Plaid for Utilities

#44

Post by drewkim »

melony wrote: post #38
drewkim wrote: post #35

Earlier quoted context omitted.

UtilityAPI and other products are built by energy companies, not tech companies. We've talked to developers who've used these platforms and they consistently mention an extremely poor developer experience; lack of clear documentation, difficulty in building integrations quickly, little to no support, etc. One example: we talked to a paying customer of UtilityAPI who asked for a specific feature, and UtilityAPI asked…

The pricing feels really steep. For a consumer app where the API is called twice a day, it is almost 7 dollars per month alone. This is just for one user. At this price point it means this is inaccessible for anything other than enterprise apps.

That makes sense; we'll need to think more about pricing consumer differently than enterprise because we've heard that our pricing is actually quite low for enterprise. Appreciate the perspective!

Re: Launch HN: Pelm (YC W22) – Plaid for Utilities

#45

Post by drewkim »

ok_dad wrote: post #41
drewkim wrote: post #35

Earlier quoted context omitted.

UtilityAPI and other products are built by energy companies, not tech companies. We've talked to developers who've used these platforms and they consistently mention an extremely poor developer experience; lack of clear documentation, difficulty in building integrations quickly, little to no support, etc. One example: we talked to a paying customer of UtilityAPI who asked for a specific feature, and UtilityAPI asked…

https://utilityapi.com/about I think UtilityAPI was founded by "tech people" as well. I wonder if you have any specific examples or comparisons that would make me want to use your service over a well-established company? I work in the energy industry, and while I would love to just try out your service for comparison, I don't have the time. Your site is very lacking in details. Also, you said you know how to build a…

Thanks for the feedback; as an early stage startup with two employees, we'll often miss things here and there, so I appreciate the callout for how we can improve our docs. While we may not be established right now and have some work to do, I'm confident we can build an amazing developer experience given time. UtilityAPI might have very detailed docs, but we think the end to end usability is still lacking. This has been the consistent theme we've heard from developers that we've interviewed.

I'm not sure I agree with UtilityAPI being founded by "tech people", though we may have differing definitions on what that means. It seems like most of the high level execs come from the energy industry and don't have software engineering experience.

Could you give examples of the specific details we could add to the website to make it easier for you to onboard?

Re: Launch HN: Pelm (YC W22) – Plaid for Utilities

#46

Post by danuker »

melony wrote: post #39
jdprgm wrote: post #37

Ha, I spent a few years around 2015 building exactly this for the first 50 or so largest US utilities on what eventually became https://www.arcadia.com/arc . Curious how you plan to compete. Good luck with the insane number of account edge cases that start popping up at scale and extremely finicky utility sites for scraping, it gets old fast.

What's the pricing for arc?

Whatever the customer is willing to pay, of course :)

Re: Launch HN: Pelm (YC W22) – Plaid for Utilities

#47

Post by drewkim »

melony wrote: post #40
drewkim wrote: post #32

Earlier quoted context omitted.

It's definitely on our roadmap...when we get to it largely depends on the needs of our early customers but know that we have it in mind!

Do you have a developer sandbox with some example data? It's not feasible for the developer to create accounts with different providers if some are across the country.

We do! You can call our endpoints with a "sandbox" header to get mock data. I realize this isn't outlined in our docs--we'll fix that ASAP and I'll comment here when it's done.

Re: Launch HN: Pelm (YC W22) – Plaid for Utilities

#48

Post by drewkim »

jedberg wrote: post #36

I'm not making an app but I would love (good) API access to my own data. I see you have a free tier that would totally work for me, but it's not clear if using it for personal use is ok?

Personal use is totally okay and we'd love to here your feedback!

Re: Launch HN: Pelm (YC W22) – Plaid for Utilities

#49

Post by drewkim »

melony wrote: post #39
jdprgm wrote: post #37

Ha, I spent a few years around 2015 building exactly this for the first 50 or so largest US utilities on what eventually became https://www.arcadia.com/arc . Curious how you plan to compete. Good luck with the insane number of account edge cases that start popping up at scale and extremely finicky utility sites for scraping, it gets old fast.

What's the pricing for arc?

Arcadia requires their customers to sign NDAs and locks them into yearlong contracts, so we don't have an accurate picture. However, we've been told that our pricing is more competitive than theirs.

Re: Launch HN: Pelm (YC W22) – Plaid for Utilities

#50

Post by drewkim »

jdprgm wrote: post #37

Ha, I spent a few years around 2015 building exactly this for the first 50 or so largest US utilities on what eventually became https://www.arcadia.com/arc . Curious how you plan to compete. Good luck with the insane number of account edge cases that start popping up at scale and extremely finicky utility sites for scraping, it gets old fast.

We're excited for the challenge!

Arc was released after we'd already been working on this for a while so it did take us a bit by surprise. We'll compete by focusing on building an amazing team and a high quality product.

Post reply on HN