I'm a FE developer on Arc (Arcadia’s API Platform), and I was surprised to see how similar Pelm was to some of the projects I've worked on, considering the release of Arc "took you by surprise."

Your designs on your website look very close to the design of our connect widget and even has the same copy.

For example, this is the Arcadia landing page: https://i.imgur.com/FkPq6S5.png While this is the landing page on your website: https://i.imgur.com/dVVOSqD.png

It gets worse on the "success" screen: https://i.imgur.com/kzgyTwv.png

I'd like to view this as a coincidence, but I viewed your Pelm-Connect repo and thought the documentation looked familiar: https://i.imgur.com/hYWIk6d.png

I looked at the commit history in the git repo, and found it was copied from our documentation: https://i.imgur.com/DF8aqFl.png https://github.com/Pelm-Technologies/react-pelm-connect/comm... https://github.com/Pelm-Technologies/react-pelm-connect/comm...

Our whole team has worked hard on our API for months, so it's really disheartening to see it copied like this.

If anyone is interested in Arc, which supports 125 utilities and has had people working on the utility data problem for 5 years, you can sign up at https://arc.arcadia.com/signup.

Regarding the similarity in design, I believe this is a result of both of our products finding inspiration in Plaid. Plaid has played an insurmountable role in the fintech boom, and I’m sure most could understand why companies like Pelm and Arcadia would look up to them for inspiration.

Regarding the similar copy in our documentation, this was something Pelm could have handled better. Our intention was to find a template as a starting point to work off of, and in hindsight, we should have just started from scratch. We’ve completely rewritten our Pelm Connect documentation.

Please understand that we had no malicious intentions and did not mean to discredit the hard work of Arcadia. We believe that Pelm and Arcadia have the same goal of democratizing access to energy data in service of making the world more sustainable. We’re excited that competition in the space will spur innovation and help us move closer to solving a dire problem.

Can’t wait to see when your copy of Arcadia’s work is finished!!!

"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!

Thanks again for building this!

If not, I’d love to get a more accurate estimate from solar companies without having to fish around for my average usage.

In fact, our frontend plugin was also called "Connect".

As an end user, it sounds like you will take my credentials for my utility provider, log into their website with those credentials, extract my data, store it in a normalized form in your DB, and expose it through your REST API.

Is this true?

If so, while you are logged in, you will also have access to financial information (e.g. bank account information, billing info, etc.). This is pretty sensitive data. What kind of guarantees are you making about not touching that data?

(All this assumes that my model for how Pelm works is true. Apologies if it isn't.)

First guarantee is that nobody is manually going in and poking around your account details since the process you've described happens entirely programmatically.

Now, we could program our system to do things other than what's mentioned. However, we're quite disinterested in (actually, emphatically against) ruining our trust/reputation with customers (plus the general public) given our dependence on such relationships and desire to succeed as a company. All that's to say, the second guarantee is that we won't be touching such sensitive data unless given permission to do so by the user.

An example of when we might need to is if the user wants to pay their utility bill using stored payment options instead of submitting payment information. Even in this case, there won't be human eyes on this data; only our Python backend will be interacting with it.

I don't doubt your intentions but these guarantees don't hold their weight relative to the sensitivity of the data that you will safeguard. Despite the process happening programmatically, developers will still have access to the backend where this occurs. Who has access to this backend? What's stopping any of your engineers from peeking at the database where the credentials are stored? Is this data encrypted at rest and transit? What sort of information is this process logging to either first-party and third-party services? Will the code be audited? What sort of compliance certifications are you planning to obtain?

Maybe you do have answers to these questions so if you do I suggest that you communicate how credentials are properly safeguarded. The guarantees that you mention in this comment don't inspire confidence as a) they can't be taken at face value b) makes me doubt you are taking the due diligence required to manage this data.

Take a look at these examples of companies supporting their claimed guarantees:

* https://1password.com/soc/

* https://plaid.com/safety/

Our process for safeguarding credentials is mentioned further down in the thread.

I'm not sure what more guarantees we can give to inspire confidence other than statements taken at face value. We don't have the scale or resources to undergo rigorous third party auditing at the moment. On the other hand, one of the first conversations my co-founder and I had was about hiring a security engineer as soon as we could afford one; we definitely take the matter seriously. Did you have any other ideas of ways we can showcase our commitment to security/privacy other than "trust us"? I do agree it's not the best method but am unsure of alternatives.

If I were interested in purchasing this service I would want to know how much I can trust you with my credentials. Perhaps having a page or section in the docs that explain the security measures would be an improvement. There are other ideas in another comment similar to this one.

1. Running such a business as an entrepreneur.

2. Running such a system as an engineer.

As an entrepreneur, are you promising your customers clean data regardless of the source? Are you promising AI magic? Are you promising a maximum failure rate?

From an engineering standpoint, how will you deal with portals changing their frontends and breaking your scrapers at any time?

I cannot know what you will do in response to these pressures, but I do know that the temptation will exist to build a system that puts a human in the loop to manually collect data from portals, to manually evaluate scrapers, to manually sift through the data and figure out what kind of Machine Learning models you can use to make your business function more effectively.

I don’t personally need the answers to these pair of questions, but I wanted to put them on your radar if they’re not already. I trust Plaid far enough to scrape account providers for me, but I do not trust Plaid far enough to provide Plaid my payment details — even if Plaid could theoretically construct them, that’s just not the relationship I want with a data conduit provider.

- Am I behind on my power bills? By how much?

- How many credit cards do I have on file and how many are expired?

Such information is still sensitive even if it doesn't leak full credit card numbers.

Also, anyone who has ever used City of Palo Alto Utilities should probably fear for their credit card information.

If I can request a utility, could you support National Grid https://www.nationalgridus.com ?

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.

FWIU, it's pretty easy to add OAuth support to any HTTP API endpoint with e.g. Nginx auth_request or by integrating an OAuth library with automated tests into the application at the url routes, if nothing else.

Do you have a "Guide for utilities who want users to have a safe third-party read-only API", a Developer portal, or like a decision tree for which script to read a decision-maker or a front-line lackey who doesn't know anything about APIs?

Does Pelm integrate with Zapier? https://zapier.com/platform

Edit: Maybe nevermind, I think I read the sentence incorrectly. You are saying you will have ComEd integration soon?

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.

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.

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.

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.

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.

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?

[1] https://news.ycombinator.com/threads?id=diafygi

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"
        ]
      ]
    }

    {
      "account": {
        "id": "1234567-123",
        "unit": "W",
        "account_number": "987654-1",
        "address": "AN_ADDRESS"
      },
      "intervals": [
        [
          "(1234567.4, 123.0)"
        ],
        [
          "(1234568.4, 123.0)"
        ],
        ...
      ]
    }

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,
                ...
            ]
        ]
    {

    "intervals": {
        [
            "meter_id": "meter_123456",
            "units": "W",
            "timestamped_values": [
                ["2022-01-01T12:45:15.123456+00:00", 1500.0],
                ...
            ]
        ]
    {

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.

Despite all the best efforts by any company engaging in this practice to protect your passwords, these entities are setting themselves up to have a huge target on their back. The technology they employ relies on being able to decrypt passwords programmatically which means it becomes visible on the server’s RAM and could potentially be triggered to decrypt the password as part of an attack. Given that a majority of people use the same passwords for multiple services, it is likely an attacker would be able to determine credentials for someone’s bank or email account via a credential stuffing attack.

Plaid with a bank that does not support oauth scares the hell out of me and I have backed out of using services because this was the only way to enter bank details. I am still shocked that this is largely considered an okay practice.

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.

Which links in particular are broken/where did you see that tagline? I thought we combed through pretty thoroughly but maybe not.

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.

(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)

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

Don’t worry though, I saved a copy of the HTML and cloned the repo for posterity :)

Thanks.