Product design · Design engineering
Designing an Energy App Directly in Code
How I used AI to move from client meetings to a live product without Figma
Yutugy helps French households decide when to use electricity. That means turning meter readings, market prices and grid data into something a person can act on, even though the three arrive at different times and with different certainty.
I joined as design engineer for six weeks. I redesigned five connected surfaces and implemented them in the client's own repository. That implementation is live today.
- Role
- Design engineer
- Scope
- Five product surfaces
- Outcome
- Five connected product surfaces implemented in the client repository
- Status
- Live
- Duration
- Six weeks
- Evidence
- 43 of 45 commits on main
- Product
- yutugy.com ↗
I designed in the product
Figma was one option in my original proposal. We chose code because Yutugy was already being built with AI, and a working branch could enter that workflow directly.
Responsive behaviour, actual chart interactions, long labels and missing data were present from the start. Each review happened in the browser, around the same interface that shipped.
The first pass focused on consumption graphs. It was a contained place to settle typography, periods, chart behaviour and responsive rules before carrying them into the dashboard and the rest of the product.
AI could draft. I decided what was true.
After each meeting I kept the transcript as the record, and let AI draft the summary from it. AI then compared the draft with the brief and running decision log, flagging contradictions and ideas that had been mistaken for decisions.
I read every draft against the transcript before it counted as settled.
The reviewed decisions became the input for the next code pass and the agenda for the next meeting. Codex and Claude worked from the same handful of project files: the brief, decision log, meeting summaries, design rules and one specification per surface. They proposed and implemented; I decided what needed another conversation and what shipped.
When the same rule kept coming up in reviews, I turned it into a check: 18 checker files in all, with one local gate running 16 of them. The engagement came to 45 commits touching 70 files.
The interface had to work with real data
Working in code brought the data constraints into the design. Linky readings can arrive late. Tomorrow's price can be estimated before publication. Some network forecasts may not be available at all.
On the dashboard, I replaced separate Today and Tomorrow tabs with one continuous timeline, and gave every value a treatment matching how well it is known. The legend names all three: published, estimated, unavailable. Unavailable hours stay —rather than being filled in, because the interface never extends a network curve just to make the chart look complete.
Missing consumption follows the same rule. The selected period sets the chart grain automatically, from hours for a day to months for a year. If Linky history stops partway through a period, the remaining space stays empty instead of becoming zero or an invented connection.
I removed an answer the product could not defend
The French dynamic-price page included a generated advice card called “Notre conseil.” During a review, Antonin argued that this surface should show the comparison without adding an opinion the data could not support. I removed the card in the next code pass.
The underlying comparison stayed. It shows the regulated reference beside the household's dynamic price across four periods. I placed real cost before hourly price because the first answers the household question and the second explains the shape of the result. That order is my design judgment, not a tested outcome.
The rules travelled across five surfaces
The same hierarchy, provenance and responsive rules carried into the remaining pages, while each surface kept its own job.
What shipped
Yutugy is live at yutugy.com, with five surfaces implemented in the client's repository. This case documents delivery and decision quality: the shipped interface, the trail of what was decided and rejected, and the local checks used to verify recurring rules. I am not claiming adoption or usability impact without data to support it.