Design-to-code
eSIM Simple
Designing and coding a product end to end with AI, from the first screen to the shipped frontend.
- Thales
- Product Designer
- 2 months to first version
A prototype built to be shown, and written to be kept.
- The product: a two-sided eSIM order management space, an operator back office and a client area. First version shipped in 2 months instead of 6, same team size, with a frontend taken into production as is.
- The validation: no upfront research. Five demos, two of them in front of real clients, led to the decision to industrialise.
- My role: Product Designer, sole designer, in a team of six.
Nomad · fictional operator
Two faces, one application
The operator's team manages partner accounts and orders. The partner browses its catalogue of profiles. The two must never see the same thing: a switcher on the header avatar moves between them, with no sign-out.
Partner accounts
| Status | Actions | ||||
|---|---|---|---|---|---|
| Solaris Mobile | SOL-6690 | LYN | Draft | 11 Mar 2026 | |
| Corvus Wireless | COR-8834 | PRTHMBGDN | Pending | 03 Mar 2026 | |
| Verano Móvil | VER-5093 | LYNPRT | Active | 28 Feb 2026 | |
| Meridian Telecom | MER-4471 | LYNPRTHMB | Active | 14 Feb 2026 | |
| Kestrel Connect | KES-3318 | HMBPRTSEV | Active | 07 Feb 2026 |
Click the avatar to switch. Reconstruction on « Nomad », an invented operator: no real data, brand or interface.
From an interface test to a product mandate
eSIM Simple started as a small React prototype I had coded to test a new interface direction. The PM saw a product in it. Management then gave us a mandate: run a product end to end, using AI at every step. Dedicated consultants set up the tooling.
The product serves two audiences. The operator back office and the client area share the same objects (accounts, profile batches, orders), with different permissions and reading priorities. I designed them together, as one system seen from two angles.
My role
Product Designer, sole designer, in a team of six: a PM, an architect, a Scrum Master, two developers.
Ideation, information architecture, screen design, coded prototyping, through to the shipped frontend. Each screen started from sketches and journey mockups in FigJam, validated with the PM, then was built directly in code.
The validation: five demos
This project had no user research phase: the need was scoped upstream. The question was elsewhere: does the product hold up when handled with real data?
The PM ran all five demos: for the sales teams, for management, and twice for real clients. They led to the decision to industrialise. The product is now being rolled out.
The key decision: prototyping a shippable product in code
A mockup can't connect to real data: hundreds of profiles, contradictory states, edge cases no one ever draws. I prototyped directly in code, with design system components, error states, responsive layouts and accessibility, as if the prototype were going to production.
The cost: reining in the AI, which spontaneously produced code outside the design system (a table imported from Material, a blue missing from the palette). The system's rules were written down nowhere, so I opened a parallel workstream to encode them. Teaching an AI a design system it has never read.
The gain: the prototype served as the specification. At handoff there was nothing left to translate, so nothing to interpret. Technical constraints surfaced during design, while trade-offs were still possible. The shipped product looks like what was designed.
Another decision: a context switcher on the avatar
Every demo had to show both faces in the same session. The real user of this feature is the person giving the demo: logging out in front of a room costs thirty seconds and breaks the flow. I put the switch on the header avatar, a common B2B pattern that an audience reads as a feature.
The cost: two contexts coexist, and only the side panel colour signals where you are. That's not enough for an order management product. In production, this would be a matter of accounts and roles.
Results
What the prototype produced
6 → 2 months
first version shipped in 2 months instead of 6, same team size, on a project of comparable scope
with dedicated consultants to set up the tooling
Zero handoff
the frontend written for the demos is the one going into production
5
demos, two of them in front of real clients, behind the decision to industrialise
all run by the PM
Where the 4 months went.5 weeks of handoff and 2 weeks of ideation meetings cut. The rest came from development, which reused the prototype's frontend instead of rewriting it, and from back-and-forth on technical complications, settled during design rather than at handoff.
Status. Being rolled out, commercial launch planned. No real usage data yet.
What I took away
Design-to-code doesn't save time everywhere: it moves it. Upstream, it costs time, because you have to write the rules the AI must follow and uncover the ones nobody had ever stated. Downstream, it gives a lot back, because handoff has nothing left to translate.
Its limit sits exactly where its cost does: you can only encode rules that already exist. Wherever the design system was silent, the AI made default choices that had to be settled one by one.