This week I wanted to “just start mobile development” for my checklist service: build a straightforward mobile client and cover the basic scenarios. The first questions looked practical: do I need a full editor on the phone, is the current API enough, and which stack and working setup should I choose?

But very quickly it became clear that this was not really a story about one more client. Mobile became a useful spotlight: it showed the places where I had not fully described the system as a contract, and where it still depended on browser defaults.

1) Product framing: a phone is not a second “full editor”

The request for a “full mobile editor” sounds logical until you break it down into real situations. In practice, it mixes two different user scenarios:

• edits on the go: quickly fix text, mark a step, replace one item, continue a checklist in the field;
• full editing: structural changes, bulk edits, careful work with formatting and visibility rules.

Once I separated these, the frame for the first version became much more realistic: the mobile client should first of all run checklists and support light edits, not fully copy the web editor.

This matters not because of “laziness”, but because of the cost of the tail. If you aim for full feature parity, you almost immediately pull in topics like offline sync, change conflicts, versioning, and complex UX for large edits. On a phone, these things are more expensive both to build and to use.

2) The API is “mostly enough”, but the bottleneck was not in the business methods

Then came the good news: a quick audit showed that for the first online version of the mobile client, the business contract was already mostly there. Auth, templates, checklists, instances, invitations — all of this exists. There is OpenAPI and there are types, so I do not have to guess from loose documentation.

At this point it would be easy to stop and say: “we can start building the app.”

But the real knot was not there.

The problem was that the current auth flow and session lifecycle in my project are tightly tied to the browser: cookies and expectations about how a client behaves inside a browser session.

For the web this is natural and convenient. For mobile it is not “impossible”, but it is a boundary that quickly turns into architecture debt: a mobile client should not have to adapt itself to the browser habits of the system.

So the paradox of the week sounds like this: the business API already looks mature, but the system as a whole is still not fully ready to honestly serve the same contract in different client environments.

3) The main shift: the question is not “how do I adapt this for mobile?”, but “how do I describe session behavior independently from transport?”

After several iterations, it became clear that mobile is not a demanding client that needs exceptions. It simply forces me to name what should already be defined:

• what a session means in the system (in domain terms, not browser terms),
• how the client gets and refreshes the right to make requests,
• which errors are expected and what the client should do in response,
• how all of this should be tested.

As a result, the frame became stronger: not “two kinds of auth”, but one shared session model and two ways to deliver that model depending on the environment:

• cookies — natural for web;
• bearer token — natural for a native mobile client.

This is no longer just cosmetics and not only “preparation for the future”. It is a way to bring the contract to a state where it does not depend on implicit assumptions about transport.

And this is where something unpleasant but useful came up: before that, I had not separated the layers clearly enough. I had “it works on the web” in my head, and that was enough. But as soon as a second class of client appears, it becomes obvious that some decisions are not really decisions at all, but fog.

To clear that fog, I had to lift and define several system-level artifacts independently of the auth transport:

• a description of login and session refresh flows (what the client does, what the server does);
• behavior rules for common failures (network error, expired session, invalid token, repeated request);
• a test matrix: which combinations of environments, clients, and scenarios must be tested for this to count as “real readiness”, not just a feeling of readiness.

4) An episode about the editor and the boundary of “where an agent is useful”

Against that background, there was also a revealing local episode inside the web checklist editor. For a long time I could not catch a bug: the menu behaved badly in a situation where there was not enough space below it to open normally. The problem was clearly somewhere in low-level JS/DOM/layout mechanics — a layer I know less well than the product and architecture side.

At some point I stopped pretending I should do “manual debugging until victory” and asked an agent to bring up Playwright and run the loop on its own: reproduce, measure, and test hypotheses.

This turned out to be useful not only for the specific bug, but also as a process calibration. If the task is mostly instrumental work — reproduction, changing conditions, collecting facts — it makes sense to give the machine the role of executor in the research loop. The human still holds the frame: formulates what exactly we are looking for and prevents the process from drifting into random fixes.

Weekly result

The week started as an attempt to get into mobile development, and ended with a more important result: I saw the foundations of the system more clearly.

First, I narrowed the product frame of the mobile client to something viable: launch + light edits, without pretending it should do everything the web version does. Then it became clear that business API readiness is only half of the story. Real readiness starts where auth and session behavior are described as a contract that lives honestly both in the browser and in a native app.

And maybe the main conclusion is this: new client environments are valuable not because they require a different UI or stack. They are valuable because they bring implicit assumptions into the light — especially around security, session behavior, and invariants, where “it works on the web” is not enough.