Every screen we generate is absolutely positioned. React Native gets literal left and top. SwiftUI gets .position(x:, y:). Flutter gets a Stack of Positioned widgets. HTML gets position: absolute in pixels.
This is the most consequential decision in the product and the one most likely to make an experienced developer wince. Here is the reasoning, including the part where we lose.
What the alternative looks like
The alternative is to infer layout. Look at the design, notice these three boxes are evenly spaced in a column, emit a flex container. The output reads like code a person would write, adapts to different widths, and is what most tools in this category do.
It is a better codebase. It is a worse reproduction.
Inference has to be right about intent, and intent is not in the file. Three boxes in a column might be a list that should stretch, or three placements that happen to line up. Guess wrong and the layout is subtly not the design, which the developer discovers later, by eye, at which point the time the tool saved is gone.
What owning the canvas changes
Because we own the canvas, we have the numbers. We do not have to reconstruct intent, so we do not have to be right about it.
That makes exactness cheap and makes it verifiable. The code samples in our docs are byte-compared against real generator output. If a generator changes, the sample fails the test rather than quietly becoming a lie.
What it costs
It costs responsive layout, completely.
Generated screens do not reflow. No breakpoints, no size classes, no LayoutBuilder. A screen is authored at one device size and exports at that size. Covering a phone and a tablet means drawing two screens.
It also costs idiomatic output. A Stack of Positioned widgets is not how a Flutter developer writes a screen by hand. Our output is a faithful rendering, not a well-composed component tree, and if you are building a design system to live in for five years that difference matters.
Who this is wrong for
If you need one layout that works fluidly at any width, we are the wrong tool. That is not false modesty, it is a structural property of the choice above. Tools that generate Flexbox handle that case properly and our comparison pages name them.
We would rather lose that evaluation in the first five minutes than in the third week.
Who it is right for
Application UI on known device sizes, shipped to more than one platform. If you are building the same screen for iOS, Android, and the web, and the recurring cost in your week is making all three match the design and each other, exactness is worth more than idiom.
That is a narrower product than "design to code" sounds like. It is the one we are actually building.