Fiuto: from a research project to a delivered feature

Context

The previous part showed a research finding reopening a roadmap decision: I had left sharing out of insights, the analysis the AI writes from a study’s results, and the competitive research reversed that, since the sharing components already existed for studies and launches. This part follows the resulting project through delivery: a Linear project handed to a build agent, and about six hours later the feature running in staging. In most teams that chain of briefs, plans, tickets and reviews is owned by different people; here one orchestrator runs it end to end, and the article covers the points at which it turned back to me and what I found when I used the feature it delivered.

From the project to staging

Between the project in Linear and the feature on staging there were six steps.

1. A brief, reviewed and locked before anything else starts, so that research and planning work against an agreed scope.
2. Research into how the product and comparable tools already handle the job, so the plan reuses what exists, here the sharing treatment already built for studies and launches.
3. A plan broken into phases and tickets and reviewed before the tickets are created, since a plan is cheap to change and an implemented phase is not.
4. Design for any new or changed surface, agreed before that surface is built, since the description in a ticket does not fix the states or the layout of a panel.
5. Implementation ticket by ticket, with a separate test pass against acceptance criteria where a new feature could break what is already there.
6. A deployment to an environment where a mistake costs little. During this run Fiuto had no users, signups were closed and the app was locked down, so the target was staging and the run doubled as a test of the release path before opening the app a week or two later.

01The pipeline

The /build family on a research project

/build is the delivery side of the setup whose design side, /ux, ran the first four articles. It takes the Linear project the research produced and runs the sequence the recording names in Linear: briefing, reviewing, locking, researching, planning, reviewing the plan, implementing, then a series of checks before the work goes out. The plan decomposes the project into phases and tickets, and where a phase introduces or changes a surface it attaches a design ticket that the /ux family answers, which is how the two families connect in practice.

The two tickets a phase can carry are where the run turns back to me after the brief and the plan have been approved: the design ticket brings its variants for a pick, and the QA ticket’s acceptance criteria are what I hold the delivered feature against once I have used it.

02The session

What is in this video

Before the run, the project sits in Linear as the previous part left it: a research outcome, no brief, no tickets. It is shared with a fresh build agent, and at 1:55 the sequence it is working through is visible in Linear. At 2:51 the plan is visible: phases and tickets, some tickets with a second ticket attached, a design ticket where the phase needs new or updated components, and a QA ticket with acceptance criteria, since a feature that adds sharing to a surface has to be checked against what that surface already does.

At 3:35 the design ticket is answered. Ideate produces a set of variants that I review with the agent and agree on, and I take the one closest to the sharing treatment studies and launches already have, with one difference: an insight has no roles, so the panel offers an option to remove a user from the analysis instead. Ideation does not use real components, so at 4:20 translate builds the panel in Ladle, and the run attaches a screenshot to the ticket beside the live story. The render is very close to the ideation output and to the existing treatment, which is enough for this pass.

7 min Watch on Loom

The process is long and intense, and the Linear view in the recording is probably an hour behind the run. From beginning to end it took about six hours, and at 5:08 I open the result: an insight with sharing, listing two users, me and a second account that has not accepted its invitation. That second user shows a question mark where the interface should say pending, a defect no check in the plan had caught. The share panel makes the link private or public, and at 5:58 I open the public view, which works but is thinner than I expected from a first version. I leave it for a separate /ux session. One research-driven feature, from project to staging, in pretty much one day.

The invited user showed a question mark where the interface should say pending. The public view was thinner than a first version should be. Both were found by me, after delivery, and neither had a ticket, so the plan has to describe more than the happy path of a phase. The plan now requires a QA ticket only for phases where a mistake is expensive, auth, payments, personal data, schema changes and flows across several surfaces, with a focused verification pass for every other phase; a design ticket that blocks its surface until /ux has produced a specification grounded in the component system; and a structural pass over the diff, for complexity, dead code, test gaps and drift from the brief, before the phase goes out. A review of the delivered experience by the person who asked for it remains a separate step.

Conclusion

Six hours held a brief, a research pass, a reviewed plan, a design pick, a Ladle render, the implementation and a deployment to staging. They did not hold a pending state or a finished public view, because no ticket named either, and the chain works in tickets. The order of the steps is the part worth carrying to another repository: brief before plan, plan before tickets, design before the surface it governs, one pull request per phase; it lets the chain run unattended for a working day, and it also means the delivered feature is exactly as complete as its tickets. An hour spent using the result, by the person who asked for it, is the cheapest step in the six and the one that found both defects.

Sources

• Session recording ↗Loom, 7 minutes
• Session transcriptClaude Code, the run in the recording