Lindi
MargheritaSan Marzano · basil$14.00ADDUse cases
The small changes that never ship.
Not the redesign. The padding, the label, the empty state, the step in the middle of a flow — the work every team has a backlog of, because each one costs a ticket and a rebuild. Here is what each looks like in Lindi.
Eight of them
Each one is a ticket today. None of them has to be.
- Design mode
The spacing that is wrong in production
A designer notices it, files a ticket, and it waits behind everything else because it is "just padding".
Open the screen, fix the padding, push. It is a two-line diff a reviewer approves in a minute.
- Design mode
The copy nobody wants to file a ticket for
A label reads badly. Changing it costs a ticket, a sprint, and a conversation about priority.
Select the text, change it, push. The reviewer sees a string diff.
- Design mode
Design-system drift
Three greys are nearly the same. Nobody knows which came from the token and which was typed by hand.
The canvas shows the real values, because they are the code’s. Fix them at the token and every screen follows.
- Build mode
The empty state everyone forgot
It shipped with no design, so production shows a blank panel and a shrug.
Ask the agent for the empty state; keep it or undo it, then send it for review with the rest.
- Build mode
A step in the middle of a flow
Checkout needs a tip step. It is small, but it touches a component, a total and a test.
Describe it. The agent edits the same file, shows you the screen, and writes the pull request description.
- Build mode
A second language
The app needs Arabic. Someone exports strings, someone else pastes them back, and the layout breaks.
Translate the app in one pass, switch between languages instantly, and see the layout in each.
- Code mode
A design change you have to read
A screenshot in a thread is not something an engineer can approve.
It arrives as a diff on a branch, in the files you know, with the screen beside it.
- Code mode
The change that was never written down
Six months later: who changed this button, and why?
One record holds design edits and merges together, in order, with a name on every line.
Worked example
“The dish cell looks cramped.” Forty minutes, start to shipped.
MergedRestyle dish cell on the Menu screen#412
- components/menu/DishCell.tsx+28 −9
- styles/menu.css+13 −3
<article className="dish-cell">- <Thumb className="size-10 rounded-md" />+ <Thumb className="size-14 rounded-2xl shadow-md" />- <Price className="text-sm" />+ <Price className="text-base font-bold text-brand" /> </article>
✓ dana reviewedmarco merged into main
what sofia sawMargheritaSan Marzano · basil$14.00ADD
MargheritaSan Marzano · basil$14.00ADDwhat shippedMargheritaSan Marzano · basil$14.00ADD
MargheritaSan Marzano · basil$14.00ADDShe grew and rounded the thumbnail and weighted the price on the real screen, and pushed. dana read the diff and merged it. No ticket, no mock-up, no rebuild — and the canvas now shows what is in production.
Who starts it
Whoever noticed.
- A designer
Notices it, and fixes it.
The change does not become a ticket, a mock-up and a rebuild. It becomes a pull request.
- A product manager
Asks for it in words.
Build mode makes the change on the real screens, and an engineer still reviews it before it ships.
- An engineer
Reviews it, or writes it.
The same branch, the same diff, the same merge — and the whole codebase beside the canvas when it is theirs to write.
Start with the one that has been waiting longest.
Lindi is pre-release. Get in line, and bring the change your backlog keeps deferring.