[drewkim]

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]

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]

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]

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.

[qqqwerty]

The founder is pretty active on hn[1]. And coincidentally, his most recent comment is about why it makes sense to work at an energy company as part of market research.

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

[ok_dad]

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.

[drewkim]

Thanks for the great advice! We've created more detailed responses, so hopefully there's now a clearer picture of the output for each endpoint. We've added the more implementation-heavy recommendations (like changing the request body for interval data and splitting the address schema into multiple fields) to our roadmap to be implemented shortly. Really appreciate the scrutiny; way better to work everything out now than having developers run into usability issues. Please let us know if there's anything else you notice!

[melony]

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]

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!