When I started this recording the feature was finished and nobody could see it.
This closes arc two of Building Fiuto: arc one redesigned components that already existed, and this arc took one feature from a blank screen to production. This is the last leg of it, the ship itself and the checks either side of it.
The build is the long part. The ship is a wait. What deserves attention at this stage is the three checks around it: the data, the server side, and the device.
What each environment was showing
What I built is the collaboration features on the studies list. A study is the test I put in front of respondents, and the list is where all of them sit. It adds avatars for who has access, an indicator of whether a study is public or private, and a share panel that opens directly from the list.
In the live app, at the time of this run, the list showed none of that. No avatars, no indication of the privacy setting for that specific study.
I had worked on the delivery, but it had only been delivered to staging. Staging is a full deployment of the app that I test against before anything reaches the live site, with its own database behind it. And on staging the feature was only half visible. The privacy lock on the public settings was displayed, and it showed me as the user, because that study is public. The avatars were not there at all. They are part of the last migration, and a migration is the step that changes the shape of the stored data rather than the code.
The code was there. The data it needed was not.
This is worth separating out before the ship. Half of a feature that depends on data will look broken in an environment where the migration has not run, and that is not a bug. I work out which half is which beforehand, otherwise I spend the ship debugging something that already works.
The ship
The ship takes pretty much everything from staging into the app, so what gets released is what was on staging. It was already in progress when I started recording, and I expected it to land in maybe the last minute or so.
The first thing I check afterwards is not the interface. It is whether the server-side pieces came across, in this case an edge function, which is the small server-side handler the share panel calls. Once that was active I went back to staging, where the feature was already fully available, and opened the share panel directly from the list.
What it cost
From when I started the build process, which was the implementation, to this stage, which is the finalized delivery, it was approximately three hours. In the meantime I went for a walk and went to Sainsbury’s, so it is probably more like two hours of work.
The project it came out of had been created eight hours earlier. So from ideation to delivery, one day of work.
I would not claim that as a full package. I had to deliver several other features before I got to this point, and the three hours cover the implementation of the list collaboration features, nothing else. The one day is the span from the first ideation session to the ship, with other work interleaved through it.
On a phone
There is also a mobile version, and I opened it on an iPhone, a Pro Max.
It looks pretty good. Not too bad.
The mobile layout clamps to two lines, which is what I agreed with the agent when we designed the surface. In this case nothing was clamped, because every item was short enough to sit on one line. The other half of that agreement was visible: long names truncate in the middle rather than at the end, so you can still see what each one is. That is quite valuable, especially when you have several versions of the same study.
Then the same view in the app. It works quite well, and it is exactly the same.
How to do this in your own repo
None of this needs my tooling. It needs the same three checks in your own environment.
- Before you ship, write down what should become visible and where. Split the list into what the code alone gives you and what needs data that does not exist yet. Ask your agent which of the changes touch stored data, since it wrote them and it knows.
- Promote the whole of your staging deployment, rather than releasing the individual change. Then what reaches users is what you tested.
- Check the server-side pieces first. Ask the agent which handlers, functions, or jobs the feature depends on, and confirm those are live before you look at any screen, since a missing one shows up as an interface bug.
- Open the production URL on a real phone. A narrowed browser window will not tell you how the type size and the truncation behave on the device.
- Check the responsive decisions by name. Before you look, ask the agent for the list of rules you agreed during design, in my case a two-line clamp and truncation in the middle of long names. Then verify those specific rules.
- Record the elapsed time with the interruptions in it: two numbers, one wall clock and one of work, plus a note of what else you shipped in the same window.
That closes arc two, from a blank screen to the shipped list on a phone. Arc three is about research in automated design: what decides which feature gets built in the first place.
