After 4 weeks of JavaScript and basic front-end, I was tasked with creating a full-featured JavaScript application. But what the first step was choosing a problem to solve:

I think I am safe in assuming most of us have had to go shopping for energy plans. Like many of us, I was advised to check out (it's actually required to be mentioned as the place to find the best rate on all energy bills) and I was underwhelmed at how it calculated my "best rate". The site assumes I use 1000kWh every month, exactly, and then sorts plans by lowest cost per kWh. Especially in Texas, where my usage can fluctuate between 200 and 2000 kWh a month, I was dubious about the plans it suggested were my lowest-cost options.

You may have also seen billboards for "concierge" services like These services offer to sign you up for the best plan for a fee (EnergyOgre is $10 a month). Since most plans are 12 month terms, this means you would be paying $120 for an initial match and still required to complete some steps to sign up for the plan they suggest. To be fair, their suggested plan was much better than what PowerToChoose suggested. However, I couldn't justify an ongoing cost or high cost (depending on how you look at it) for a simple matching service.

My pen-and-paper energy plan rate calculations

In the end, I always defaulted to pen-and-paper (well, actually I used google sheets) to run through a dozen plans and calculate what I would actually expect to spend next year based off my previous year's usage. This is exactly what I set out to build for my project.

Normally, this is done in a group of 4 over the course of a week. Unfortunately, I couldn't work on the project during normal hours (daddy daycare) so I asked to work alone since I didn't think it would be fair to other members of a group.

My first step was to locate a source for the plan information. I knew there must be something out there since so many of these new concierge services had to be using something to compare fast-changing plans. I figured the most likely source would be from the Public Utility Commission of Texas and it turns out that (created by the PUCT) did in fact have a "hidden" API. I say "hidden" because it wasn't mentioned anywhere and I couldn't find any terms on it's use or any documentation.

Now, the fun part. The API was not as detailed on rate information as one might expect:

plan information from the api

As you can see, there is no rate value. From my experience doing the math on these plans, I also knew to expect most of these plans would include base charges and delivery per kWh. In addition, there are many plans with special usage rates (i.e. a lower rate for usage within a certain range or certain hours).

In the end, I decided that the most-accurate information I could use to base my calculations on would be the three estimated cost per kWh (in cents) at 500, 1000, and 2000 kWh usages. Short of scraping hundreds of fact sheet pdf documents with wildly different formats searching for key terms like rate, base charge, delivery, and dozens more would have to wait for another day (if it was even possible).

Given I would be working with three data points, I quickly deduced that I'd need to calculate a rate of change between each interval to be able to calculate the cost per kWh at any given point.

example plan with the rates of change as lines between the points

So, a bit of logic and math here:

  • Plotting these points on a usage graph (above) I had 4 points to work with. X = 0, 500, 1000, and 2000.
  • A rate of change can be calculated between each set of points using Y2 - Y1 / X2 - X1.
  • Depending on where the user's usage for any month fell, a difference would have to be calculated between it and the floor usage tier (i.e. usage for month 1 is 630. so the difference between 630 and the nearest lower-point is 130).
  • The rate of change is then multiplied to the kWh estimate provided for the nearest floor usage tier.
  • This provides us the kWh charge at the user's designated usage, so it must again be multiplied by the designated usage to get the estimated cost.
  • Finally, remembering the API provides cost in terms of cents per kWh, the result must be divided by 100 to result in a final dollars per month result at any kWh usage.

There were pros and cons to this approach. The biggest pro would be that it should account for most "hidden" charges that you'd have to go hunting for in the fact sheet. The biggest con would be that it wouldn't be 100% accurate for some plans. There was no way to account for plans like "free nights and weekends", as an example. Also, The further you got from any of the given usages (500,1000,2000) the greater the margin for error could be. It was a tradeoff, but I determined that this was the most accurate means and proceeded forward.

Here you can see how the rates of change are calculated in the code

I got through a lot of the JavaScript part of the code without any major issues until I reached a point where I needed to calculate monthly and yearly totals (and what to do with those results). After a few hours of trial and error, I reached out for some help and Josh Medeski (a DigitalCrafts instructor) offered to help.

First, he help me break some of my spaghetti code into functions to make it easier to understand. Then, he helped me model how I needed the data to end up. After some discussion, we decided that it would make more sense to append the array we called for the plan information and simply use that to calculate totals and sort by ascending total cost for the results.

Completed 1.0

After that, it was just polishing up the front end and plan results. It took some time, but my experience with user-focused design and graphic design helped me come up with something I felt users would understand how to use.

I also felt it was important to be transparent, so I included information on the page about where I was getting the plan information, how I calculated the results, and why (I felt) it is an improvement over most other tools they might try. is live and I am really happy with the result. To date, it's received almost 200 users with over 100 generated plan results. I've gotten a couple requests and UI improvement suggestions that I will be implementing in the next version including filters and some error handling.

I also decided to make the project open source since I feel this could be a valuable tool for other states and/or benefit from other developers help in improving the current code.

I can't wait until I need to go rate-shopping again!

Special thanks to Josh Medeski for his help with this project!