# Zeigo Power ## Schneider Electric — 2025 --- Context: Buying renewable energy certificates as a group means dozens of companies committing volume against one price, in a window that closes on a date. Closing one of those trades was **an email thread and a spreadsheet**. Zeigo Power is the console that does it in product. My role: The **Purchase Opportunities feature is mine end to end, design and code** — the opportunity grid and its states, the commitment-window panel, the Orders tab with its statuses and rejection flows, the checkout, and the six ways a trade can close. Built on Zeus in **React and TypeScript on Next.js**. I was brought onto Power specifically for this. Impact: Closing a commitment window went from **~2 days of email and spreadsheet reconciliation to under 15 minutes** in the console, and the scenarios handled in product went from one happy path to **six**. What did not work: the product never reached the volume it was built for. Buying renewable energy certificates as a group means dozens of companies committing volume against one price, in a window that closes on a date. I designed and built the console that runs it — including the five ways it can go wrong.  Two sides use it. **EAC Control**, the Schneider team that creates an opportunity, sets the price ceiling, shares it with organizations and closes the trade. And the **buyers**, corporate procurement teams committing volume, who see an anonymised version of the same opportunity. Before the console, the price was agreed by email and the volumes tracked by hand. **The decision: treat the closing of the trade as the product.** Not the browsing, not the catalogue — the closing. There are six whole flows for it: confirm at the wholesale price, confirm with reconciliation, target not reached, zero orders, error, and cancellation. That is not defensive design. That is the feature.  You only know there are six outcomes if you know what the system does with money. The agreed wholesale price can differ from the sum of the orders placed. A window can close under its MWh target and still be closable. A window can close with zero orders. And a cancellation means **issuing refunds to people who already paid** — which is why the buyer sees a written reason on the card, not an error code.   --- **Reconciliation is the crux, and it arrived last.** At order time the buyer pays against a wholesale commodity cost. By confirmation, the cost agreed with the supplier may be lower. So the screen asks whether it changed and lets the operator enter the final figure — constrained to be **equal to or below what the buyer already paid**, because the only legal direction for that number is one that owes the buyer money. The stack recomputes in front of them and the field answers live.  Finding it late was expensive. Reconciliation is not a screen you bolt on: it changes what the confirmation step is allowed to do, so the whole closing flow got a second version. **What I'd do differently: map the money before the screens.** Every scenario I found late was a question about what happens to a payment, not about a UI. The method was flow first, literally. Every section of the file opens with its state diagram before a single screen. You cannot design a state machine in prose — you draw it, and then you find the states you missed.  - Time to close a window: ~2 days → <15 min - Closing scenarios in product: 1 → 6 - Closings needing support: ~1 in 4 → ~1 in 20 **What didn't work:** the product did not reach the volume it was built for. The console does what it should — the closing runs in product, the states are covered — but aggregated EAC purchasing never took off at the scale that justified it. The craft is in the work, not in the outcome, and I would rather say that than dress it up. --- All case studies: [https://www.exelobaiza.dev/work](https://www.exelobaiza.dev/work) (markdown mirror: [work.md](https://www.exelobaiza.dev/work.md)) ## Contact - LinkedIn: https://www.linkedin.com/in/exequiel-lobaiza/ - GitHub: https://github.com/exelobaiza