Put yourself in the shoes of a energy manager, who is looking over energy consumption of a university. Where is the energy consumed? Whats the change in consumption, in comparison to last month, or last year? Where are the emissions happening? This tool was built to help monitoring energy consumption across multiple properties & locations (eg: universities, chain of restaurants etc.)
We helped PulseEnergy (now acquired by EnerNOC), to build this tool. We worked remotely with the a team of Engineers at PulseEnergy, for over 2 years. Most of the product was written by us.
The video below, show some features of the app, allowing slicing & dicing of multiple types of data, across multiple dimensions.
We work with our clients to understand their business and concerns. ABOF, wanted a head start in their front-end dev stack. We worked on a few important pages of the incoming traffic, and replicated the same functionality that the existing IBM WebSphere based front-end offered, over the span of 3 months.
And when we shipped it, it was among the fast loading sites.
Our aim, was to give ABOF a head start with the technology, so their internal team could pick up and continue the work. We worked with their engineers, tech team and product team, to figure out what was needed, which parts could be compromised for shipping the product faster, and how to achieve the desired speeds with existing infrastructure.
With the success of the first implementation (The business saw a considerable increase in the conversion rate), ABOF asked us again, to redo their checkout process. Which, again, we delivered in 2 months, within time.
Below is the loading times of the listing page of various e-commerce sites, when we delivered ABOF's listing page.
Midtrans sends out hundreds of thousands of notifications per day. We helped them migrate their notification system to Elixir stack to improve the performance and decrease the resource consumption. The average latency of a particular set of notifications has decreased from 2.9s to 198ms. The memory consumption went down from 5.3GB to 300MB per node, which brought down the hardware cost to 1/3. This is probably a good example of how choosing a technology that fits the problem domain could improve the system considerably. More details can be found in the blog post by Midtrans.