[HN Gopher] Launch HN: Pelm (YC W22) - Plaid for Utilities
___________________________________________________________________
Launch HN: Pelm (YC W22) - Plaid for Utilities
Hi HN, Drew and Edmund from Pelm here (https://www.pelm.com). We
are building an API that allows developers to access energy data,
such as electricity usage or billing data, from utilities.
Currently, if you want to build an application on top of energy
data, you have to build integrations with utilities across the
country. Not only is this time-consuming, it's super frustrating
given the lack of data standardization and the clunky, high-
friction integration processes that energy companies use. With
Pelm, you only have to integrate with one service to access utility
data, and you get to use a seamless, well-documented API built by
other developers. We are software engineers (from Asana and
Affirm) who are enthusiastic about sustainability and the creation
of a more modern energy grid. We talked with lots of developers who
were frustrated from trying to work with energy data and saw an
opportunity to meet their needs while supporting the push for a
more efficient energy grid. Most companies trying to tackle this
problem are energy companies, not technology companies. The
products they build don't keep the user in mind and only focus on
meeting bare functional requirements. Pelm, by contrast, is by-
developers-for-developers. Our focus is ease of use. Our API is
simple to get up and running (under ten minutes) and provides clear
documentation and instructions. It works like this: you register
for our service and embed Connect (our front-end plugin) into your
application. The end user uses Connect to authorize access to their
data from their particular utility. We scrape electricity usage and
billing data from their utility account and store it in a
standardized format in a database. Your application can then query
electricity interval data and billing data for the end user through
our REST API. We also recently built out functionality to pay
utility bills through our API. Our API is designed for apps that
do things like help consumers reduce electricity usage, charge EVs
at optimal times, optimize HVAC installs, or educate on climate-
friendly practices. One example of how Pelm can currently be used
is in demand response programs--that's when utilities pay companies
to get large amounts of people to reduce their electricity
consumption during peak hours. Our API can help measure the
reduction, which determines how much the company gets paid. Another
example: solar panel installers can use us to show potential
clients how much they could save on their electricity bill by
installing solar. Another is community solar programs that allow
people to buy into remote solar farms and get credit for the
generated energy from utilities. Pelm can be used by community
solar providers to calculate and bundle bills. (By the way, an
interesting little-known fact: this space is possible because of a
2012 initiative by Obama that required utilities to allow consumers
more visibility into their energy consumption habits.) Pelm is
free up to 100 API calls and 10 active end users per month. After
that we charge on a usage based plan: $0.10/call and $0.50/active
end user up to 10,000 API calls and 1,000 active users. Past that
limit, you'll move onto an enterprise plan with a flat monthly rate
based on your service level and an adjusted rate for calls and
active end users (we're still figuring out the exact parameters).
We'd love to hear any of your ideas or experiences within this
space! We're always looking for creative approaches to the problem
and ways we can better the developer experience we're building. If
you get a chance to test out the API, please share your feedback on
how we could improve it. Thanks so much!
Author : drewkim
Score : 72 points
Date : 2022-02-09 16:16 UTC (6 hours ago)
(HTM) web link (www.pelm.com)
(TXT) w3m dump (www.pelm.com)
| dmitrygr wrote:
| 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.
| kolanos wrote:
| If utilities gave them any other way, I'm sure they'd be using
| it.
| dmitrygr wrote:
| That is a poor excuse for a clearly bad security practice.
| That is akin to a mugger saying "if the world gave me another
| way to make money, I wouldn't be mugging people". Some things
| just shouldn't be done! This is a hill I'm willing to die (by
| a thousand downvotes) on!
| jzig wrote:
| I work on the JSON API (I dare not call it REST) layer at Exelon.
| This is neat. Did you know we have some OpenAPI docs now? I saw
| you mentioned ComEd in another comment :)
| drewkim wrote:
| I did not; thanks for the heads up!
| jzig wrote:
| 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!
| drewkim wrote:
| Ah, nice! Getting all of Exelon for the cost of one would
| be quite awesome. We'll dig into it.
| chopped_onion wrote:
| I'm an engineer (turned product manager) working on Arc:
| https://www.arcadia.com/arc. We experienced a lot of the same
| developer experience and coverage issues with other solutions.
|
| To date we have coverage of 120+ utilities all over the country
| and many of our paying customers have praised the developer
| experience. You can sign up for API keys and try it out here:
| https://arc.arcadia.com/signup.
|
| OP, I'm curious what specific developer experiences or tools or
| data coverage you feel are lacking from what we've put together.
| jedberg wrote:
| 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?
| drewkim wrote:
| Personal use is totally okay and we'd love to here your
| feedback!
| JaakkoP wrote:
| Really cool use-cases! I wonder why you decided to move them
| under a separate page instead of showcasing them front and
| center?
|
| Right now the focus seems to be how easy it is for developers to
| get going, but it doesn't really talk to me _why_ I should be
| doing it.
|
| Once I read the use-cases I get the idea and I'm impressed, but
| the drop off from people not bothering to click on a 2nd page can
| be surprisingly big.
| drewkim wrote:
| Thanks for the feedback! We had optimism that people would poke
| around the website more, but I guess we shouldn't assume that.
| dang wrote:
| That's a great point. I've changed the linked URL above to
| https://www.pelm.com/use-cases. Thanks!
| jdprgm wrote:
| 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.
| drewkim wrote:
| 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.
| melony wrote:
| What's the pricing for arc?
| danuker wrote:
| Whatever the customer is willing to pay, of course :)
| drewkim wrote:
| 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.
| samwillis wrote:
| 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? Again may
| be worth listing them on the site.
| drewkim wrote:
| 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.
| woqe wrote:
| 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.
| drewkim wrote:
| 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.
| samwillis wrote:
| 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.
| drewkim wrote:
| We use a secret manager on our cloud platform for key
| storage, manually rotate keys (for now), and store
| encrypted passwords on a separate db.
| samwillis wrote:
| Perfect. Thanks.
| jzig wrote:
| I'm confused, ComEd is an Exelon opco but PG&E is not. Or
| does ComEd mean something else here?
|
| Edit: Maybe nevermind, I think I read the sentence
| incorrectly. You are saying you will have ComEd integration
| soon?
| drewkim wrote:
| Correct, we'll have a ComEd integration soon
| ok_dad wrote:
| How is this differentiated from UtilityAPI
| (https://utilityapi.com/) or other similar products?
| drewkim wrote:
| 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 him to pay
| for the development costs of it.
|
| We are software engineers by trade and know how to build a
| really good developer experience. We're focusing on ease-of-use
| from the start and will build a stellar engineering team that
| in turn will help us develop a higher quality product.
| ok_dad wrote:
| 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.
| drewkim wrote:
| 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?
| ziggus wrote:
| The founders may have energy industry experience - which
| is what you want, since it's the operating domain and
| they'll have industry information and contacts that
| 'outsiders' won't - but they seem to have a pretty strong
| development team: https://utilityapi.com/team.
| ok_dad wrote:
| I would have the docs much more specific on the results
| that you'll get back. I think from the looks of it,
| you're using some automated doc builder which takes your
| internal specs for the endpoint (like the OpenAPI spec or
| whatever) and outputs "examples" and the other doc pages.
|
| Here is what you have now for an example response body,
| which is very lacking: {
| "account": { "id": "string",
| "unit": "string", "account_number": "string",
| "address": "string" }, "intervals": [
| [ "string" ] ]
| }
|
| I would show something like this (clearly I don't know
| the exact formats or what each value is, so this is just
| illustrative): { "account": {
| "id": "1234567-123", "unit": "W",
| "account_number": "987654-1", "address":
| "AN_ADDRESS" }, "intervals": [
| [ "(1234567.4, 123.0)" ],
| [ "(1234568.4, 123.0)" ],
| ... ] }
|
| I think your docs could use a TON of manual refactoring
| after you output them from the automated tool OR you need
| to put a lot more details in the spec so that your
| automated tool will have better results.
|
| For instance:
|
| * What is "unit"? I assumed it's electrical units, but if
| that is the case, it doesn't make much sense to me,
| because that's not an account-level detail but rather a
| request detail (I should be able to add a param to the
| request to get Watts, Kilowatts, or whatever units I want
| each time).
|
| * The "address" is also sketchy, because it is just a
| string field, so how do I parse that? will each "line" of
| the address be separated by a newline, or something else?
|
| * The spec for "intervals" is a list of lists of strings,
| which is a weird way to output `(timestamp, value)`
| tuples; I would want to see that specified a bit better
| as well. I would expect either tuples of numbers (float,
| int, whatever) or something like a mapping with the meter
| numbers, timestamps, units, values, etc. specified like
| this (timestamps could be UTC seconds or (preferably) ISO
| strings): "intervals": { [
| "meter_id": "meter_123456", "units": "W",
| "timestamps": [
| "2022-01-01T12:45:15.123456+00:00",
| ... ], "values": [
| 1500.0, ... ]
| ] {
|
| or: "intervals": { [
| "meter_id": "meter_123456", "units": "W",
| "timestamped_values": [
| ["2022-01-01T12:45:15.123456+00:00", 1500.0],
| ... ] ] {
|
| Some of this is implementation details, but format and
| documentation matters a LOT for this stuff, if you're
| providing a data API as a service.
|
| That's all just from one endpoint. If you have 2
| employees, I would look into hiring a technical doc
| writer as your 3rd if you're trying to build an "amazing
| developer experience" and also talking to more commercial
| customers who might use your product to run large data
| pipelines for energy controls and such. To me, the
| documentation is like a canary in a coal mine, and I
| wouldn't even attempt to use your product as-is because
| it would take me time to fool around with it to even see
| what formats the data is in and there is no
| differentiator from your product and others that makes me
| want to do that work.
| melony wrote:
| 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.
| drewkim wrote:
| 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!
| candiddevmike wrote:
| Some feedback: As a potential user of your product, I can't find
| a list of any utility companies you integrate with?
|
| Also it looks like you're are using Jekyll for your website ("Get
| to know Midnight Theme")? May want to finish customizing it, some
| of the menu links don't go anywhere.
| drewkim wrote:
| Thanks for the feedback--we'll have a list of utilities we
| support up shortly.
|
| Which links in particular are broken/where did you see that
| tagline? I thought we combed through pretty thoroughly but
| maybe not.
| clairity wrote:
| note that without js turned on, your "burger" menu doesn't
| even show up, so links to other pages aren't accessible. you
| seem to be targeting developers, so there's a good chance a
| number of them browse with privacy extensions. i'd also
| suspect that the most interesting traffic for you will come
| from desktop, so why have a burger menu at all? that's an
| affordance primarily to accommodate mobile users. just list
| your primary links at the top and let them wrap on mobile. no
| js needed!
|
| edit: forgot to note that "Get to know Midnight Theme" shows
| up in the burger menu, under 'Product'. you don't need either
| that 'Homepage' link, or even the 'Home' link 1 level up.
| linking home from the logo is sufficient.
| drewkim wrote:
| 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.
| clairity wrote:
| 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 about how people actually use browsers)
| drewkim wrote:
| 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!
| ctoth wrote:
| 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 for building this!
| drewkim wrote:
| 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.
| ctoth wrote:
| Oh awesome! Thanks!
| clairity wrote:
| 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.
| dang wrote:
| I've added that info to the text above.
| worldmerge wrote:
| This product seems really cool!
|
| If I can request a utility, could you support National Grid
| https://www.nationalgridus.com ?
| drewkim wrote:
| 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!
| melony wrote:
| 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.
| drewkim wrote:
| Here's the guide to using sandbox mode:
| https://pelm.readme.io/reference/sandbox-mode
| drewkim wrote:
| 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.
| dneri wrote:
| Was just looking for a solution like this to integrate with
| HomeAssistant. Looking forward to trying this out!
| drewkim wrote:
| Would love to hear about your experience when you do so!
| derekjobst wrote:
| Same!
| sealthedeal wrote:
| Hey, friendly founder advice. Your opening hero and sub text does
| nothing to actually describe what your API is. This text you
| wrote would in my opinion be way better
|
| "We are building an API that allows developers to access energy
| data, such as electricity usage or billing data, from utilities."
|
| Change it to "An API to access your users utilities"
|
| sub text: "Our API gives you access to your users energy data,
| such as electricity usage or billing data, to help build richer
| more meaningful applications in X industries"
|
| Anyways, congrats on the launch!
| sealthedeal wrote:
| Aaaannnnddd just like that your text has already been updated.
| Love the new hero text :).
| arsalanb wrote:
| Literally one minute later, wow! Love it! Congrats on the
| launch!
___________________________________________________________________
(page generated 2022-02-09 23:00 UTC)