Why Flutter took 25 extra days: closing the token foundation of the Harness Design System

The token rollout for Flutter in the Prolog app happened on 24/09, and the release for the people who use the product came out this week. React was already live, so the token foundation of the Harness Design System project is closed on both stacks, with the harness applied and tokens an LLM can consume. Call it agentic ready, LLM-readiness, or whatever name you prefer. The most structural part of the design system is ready.

This article explains why Flutter finished about 25 days after the deadline we estimated, and what that changed in how I plan design system work.

We estimated Flutter by looking at React

In React, building and testing was faster. The Flutter estimate was born from that experience, and that was the original mistake.

Flutter runs on Google's own engine, on Dart, and shares nothing with JavaScript. Figma, in Dev Mode, already exports CSS and TypeScript, and on the web the tokens come in through Tailwind without much ceremony. In Flutter there was no equivalent path. The infrastructure that receives the tokens and distributes them to each platform had to be built with Flutter in mind, and the migration of components and screens was done independently of the web.

In practice, these were two projects with the same name, and we estimated them as if they were one.

Testing cost more than migrating

On the web, the review relied on a tool that shows the current screen next to the screen with the new tokens. It helped a lot with React and was adapted later for Flutter, but Flutter required much more runtime testing, running the app and looking at the result.

Rodolfo, who led the migration in the code, described the difficulty well. The application is large, with many pages and old and new versions coexisting, which means a lot of context for an AI to load at once. He tried to orchestrate the migration in a single workflow, and the execution never reached the end. What worked was splitting it into phases.

The review had the same scale problem. One of the tools he built listed all the tokens from both platforms, and the volume reached about 7 thousand. Reviewing them one by one was not feasible. Glauber changed the method several times until we decided to go screen by screen in the app, noting where the visual problem was greatest. That let us separate what was worth migrating at that moment from what could wait. Empty states, for example, already had to be redesigned anyway, so it made no sense to spend time adjusting the old version. The criterion we used was to make the divergence imperceptible to the people using the app.

Technical debt we had not explored yet

Each stack carries its own technical debt, and part of it only shows up when someone goes into the code to make the change. The estimate, on the other hand, is made before going in. On React, the gap between what was expected and what was found was small. On Flutter, it was large.

Today I treat this debt as uncertainty declared in the estimate, and the way I calculate has changed. Before, I asked how long a stack takes. Now I ask how much of the stack I have already known from the inside. If it is little, the deadline has to come with an explicit margin, and that margin has to be communicated to leadership at the start.

Dedication dropped in the middle of the project

The second reason for the delay comes from how the team was organized. The people working on the project had to start new projects, and the time dedicated to the design system dropped to something around four hours a week, when it happened at all.

In a goal-alignment meeting, one person on the team said that without a well-defined task, four hours a week did not produce work. Another pointed out that we had been missing deadlines because none of them were realistic. Both comments were right.

Working with AI makes this problem worse. An experiment with agents requires someone to prepare the context, start the execution, let it run for hours, and then review. Splitting that into two-hour blocks per week multiplies the cost of getting back into it. During the conversation someone did the math: eight hours of work in two-hour weekly slices takes a month, and the same work fits in one day.

That is what we did. We set aside a full day dedicated to Flutter to close the remaining token gaps, and the release to production came out this week. I do not have a number to compare that day with the previous weeks, but it was what unlocked delivery, and it is the clearest lesson of the period.

Another proposal that came out of that same meeting, and that I want to try, is to measure the human cost of the project. AI execution is hard to count in hours, but you can record how much time each person had to stop what they were doing in the squad to resolve design system questions. Without that number, the project looks cheap and the team pays the difference.

What I take from this

The first change is to estimate each stack separately, without inheriting another stack's deadline. The second is to treat what we do not yet know about the code as a risk declared in the schedule. The third is to reserve full days for work that depends on long context. And the fourth is to count the cost of people who leave their own squad to work on the project, because that cost exists even when nobody records it.

The foundation is closed, and components are the next step

The tokens deliver the base: a more consolidated system, with more variants, a revised typography, and documentation an LLM can read. They do not yet deliver the result that gives the project its name, which is an AI building screens with direction. That gain depends on the components, and the proposal for this stage was presented to our CTO this week. He approved the plan.

The first decision in the plan comes straight from the Flutter lesson. Instead of loose hours during the week, the team will meet in person one full day a week, focused only on the project and without interruptions, until the end of October. We considered biweekly meetings, but that would give too few working days until then, which is too little for the scope. We also doubled the hours we had planned before, and the impact on people's other work was agreed in advance.

The work runs on two fronts at the same time.

The first is a skill, a reusable instruction that Claude Code follows, to evaluate screens. It compares the screen created with Prolog screens that work well, gives a score from 0 to 100%, and suggests what to adjust. Screens with 80% or more go through without design review. This helps mainly with simple screens, such as those that follow our pattern of tables, filters, and side-panel navigation, which development people already create on their own with AI today.

The second is applying the harness to about 60 components of our design system. There are other components that are not yet in the correct design system repository, and they will wait. For this work we will adapt a command-line tool from Astryx, an external project that has already solved how to prepare a component catalog for AI agents. We decided not to rewrite the components now. Rewriting would require testing how each one works, and today we have no tests for that. That path remains the ideal in the medium term, but it would increase the risk of delay.

In the presentation, the CTO made an observation that changed the first front. The score cannot be just a percentage, because some errors need to block the screen. Our pattern for showing the details of a table row is a side panel. If someone uses a window that opens in the middle of the screen, it must not lose 10% and move on. It should go back for adjustment, because a ready component already exists for that. The skill now has, in addition to the score, a list of blockers.

How to measure that percentage in the components is still an open question. We will answer it on the first day of work, and by around the second day we will know whether the AI creates better screens with the harness. For now we have scope, a deadline, and this question declared.