Live data from Hacker News

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

pelm.com

21–30 of 91 posts

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

#22
post #13
post #12

This looks pretty great. My first potential use case is as for a HomeAssistant addon to tie into HA's existing energy monitoring infrastructure. Is there any chance of a free plan for consumers so we don't need to sign up and pay $3.00 a month to retrieve energy usage for home use? I imagine that the mindshare among developer types would be worth the minimal calls, but obviously this is your decision :) Thanks again…

Pelm is free up to 100 API calls and 10 active end users per month! I believe this should be enough to cover the home use case.

i was also wondering about this right off the bat. it's something i'd prominently explain right at the beginning on the home page, because you want trials to be exceedingly obvious and frictionless (and without having to have you two involved!). it's a great way to build your funnel (and get word-of-mouth) at low cost.

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

#24
post #18

Earlier quoted context omitted.

Ah, it's the burger menu with broken links! It shouldn't show up unless the browser window is a certain width, but we'll look into scrapping it completely.

cool, i'd suggest the only links you need at the top are 'How it Works', 'Pricing', 'Blog' (for marketing), and 'Contact' (for sales). (edit:) oh yes, and also your call to action, 'Get API Keys'. everything else is footer material, and you already have a fat footer with most of those links anyway. (i should note that i usually browse in narrow windows, so i often get the mobile version; most designers don't think ab…

Gotcha. Makes sense to keep things simple.

You're not the first person to suggest a blog for marketing purposes...seems like something we should invest in!

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

#25
post #20
post #11

Earlier quoted context omitted.

I did not; thanks for the heads up!

Yeah so besides ComEd, I wouldn't think it would be too difficult to integrate with the other five opcos that Exelon owns because they all use the same api layer. This would double your number of energy customers from ~4 million to ~10 million ;) Of course, I have no idea what sort of arrangement you initiated with ComEd!

Ah, nice! Getting all of Exelon for the cost of one would be quite awesome. We'll dig into it.

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

#26
post #6

Two questions: How are you connecting to the users energy supplier, I assume most don't have their own apis and so you are having to save the users login credentials? If so you should list the security measures you are taking to ensure that are safely stored. This is much like how developers had to connect to banks before they started supporting standard apis. Which utility companies can you currently connect to? Aga…

Great callout. Passwords are encrypted using a 256-bit AES cipher and are never persisted or shown to developers in plaintext. We currently support PG&E and SCE with a ComEd integration landing within the week.

Can you go into more detail about this? I may be misunderstanding, but I read 'never persisted' as meaning my users must provide credentials for every API call.

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

#27
post #26
post #6

Earlier quoted context omitted.

Great callout. Passwords are encrypted using a 256-bit AES cipher and are never persisted or shown to developers in plaintext. We currently support PG&E and SCE with a ComEd integration landing within the week.

Can you go into more detail about this? I may be misunderstanding, but I read 'never persisted' as meaning my users must provide credentials for every API call.

Ah, I meant plaintext passwords are never persisted in a db anywhere. The only time passwords are decrypted are when they are used to programmatically log in, so they're never stored anywhere except in memory.

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

#29
post #27
post #26

Earlier quoted context omitted.

Can you go into more detail about this? I may be misunderstanding, but I read 'never persisted' as meaning my users must provide credentials for every API call.

Ah, I meant plaintext passwords are never persisted in a db anywhere. The only time passwords are decrypted are when they are used to programmatically log in, so they're never stored anywhere except in memory.

Out of interest what’s the architecture you have gone with for key rotation and storage, and where the encrypted passwords are stored. (Understand that as an very early stage startup you probably haven’t optimised all this yet)

I know some other services that have had to go this route have used quite elaborate systems to ensure separation between keys, passwords and user details in the event of a hack.

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

#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.
Post reply on HN