System design (and business case) for a EV charging station backendSat Feb 13 2021
There are 600,000 private cars in Singapore. Right now, 600 of them are (fully) electric.
By 2030, the SG government wants to have 60,000 chargers installed island-wide. Suppose there are 60,000 electric cars. These electric cars need to be charged at chargers. An average driver drives about 50km in a day. That means 10kWh. The business model has us charge 45c per kWh. So that means that each charger makes about of revenue. Power from the grid costs per kWh, so that's in profit per day.
A Toyota Corolla Altis gets an average of kms per liter source. At 50km, this is liters of fuel per day, which at a fuel cost of equals . So the electric car driver saves almost 40% on fuel costs.
Suppose there are 60,000 electric cars (10% market penetration) and each of them gives us of daily revenue, then the total addressable market is , or almost 100 million dollars in revenue per annum.
Meta-question: when is it better to build your own v. outsource the software development?
Should ask Ben about this.
PlugIT (website in Finnish) offers a SaaS that makes the backend easy. It charges $21/month per charging station with an additional fee per charging transaction.
On the one hand, since PlugIT has already gone through all the hard work to develop this software, we would certainly incur a very high fixed cost to do the R&D in-house (especially if we're hiring top engineers, which we will want to).
On the other hand, in the long run building your own software would make financial sense. Suppose the company manages to install 4,000 chargers. Then at 21 dollars per charging station per month that's per month: enough to hire 5 or 6 full-time excellent SWEs to develop the front- and back- end and maintain it full-time. At the time of its acquisition, Instagram had 6 engineers supporting 30 million users, Even with a 50% volume discount this would be per month, enough to support three full-time engineers. I hear that PlugIT also takes a 1% extra transaction fee per transaction. Assuming just one transaction per day per charging station, that's per transaction, which is per month.
Also, an argument could be made that this is critical software infrastructure that should not be outsourced. Without the backend your company literally cannot make money (cannot take payment). It might not be a good idea to be reliant on a single company for all of your infra.
There are also more nebulous advantages wrt owning your own data, adding new features etc. For instance, you might be able to use the charging data to optimise charging patterns
I think it all depends on how much scale the company has. With only a few chargers it doesn't make financial sense to build your own software, but it does when you do have 4,000 chargers.
The user first registers himself with the app and saves his credit card data. Subsequently he can drive up to any of the charging stations, press a button on the app to start charging, and plug the charger into the car.
On the backend once we receive a charge request this backend should send a "start charging" request to the charger via the OCPP 2.0 protocol. On the frontend the app will tell him how much energy he's used so far (ideally also battery percentage) and the cost incurred.
When the user finishes charging he again presses a button on the app which sends a "stop charging" request to the charger, which releases the safety lock and allows the user to unplug the charger from the car. A payment transaction is created on the backend and the user is charged appropriately.
OCPP 2.0 protocol
Questions to ask
Storing sensitive credit card data?
Server can never go down otherwise you literally cannot take payments and your business is dead in the water
WHat happens if the server stops responding? you must not have mechanical locks be software controlled