Phone or watch — which one should do what?
I wanted an app of mine to work not just on a smartphone, but on a smartwatch on your wrist as well. The moment I started thinking about it, the first thing I ran into was the question of how to split the roles.
Should both of them be able to do everything, exactly the same? Or should each one do what it is good at?
Turning that over inside my own head, it just got more and more tangled. So, as usual, I asked my AI partner Kuro (Claude) to help me sort it out.
This will come out cleaner if you split the roles instead of making both of them do everything. Which one is the lead and which one is the supporting act? Let’s decide that first.
The mother ship and the sidekick
What we arrived at, after talking it through, was a very simple division.
The smartphone is the mother ship that can do everything on its own. Putting information in, adding it up, showing the result — all of it starts and finishes inside the phone. Even with no watch at all, the phone on its own works properly. That is the base assumption.
The smartwatch, on the other hand, can only do input. You tap away at it on your wrist and it sends the information over. The phone catches it, and the phone handles every bit of the fiddly processing that follows. The watch is purely a supporting partner, adding the convenience of “you can also enter it from your wrist.”
If you try to make the watch do difficult things, the screen is small and the operation gets painful. So be decisive and cut the watch down to “just tap.” In exchange, the phone does the real work. That relationship feels good.
Subtraction, not addition
Once it was clear which one was the lead and which was the support, the fog in my head lifted.
Not being greedy with the watch — not piling this and that onto it — is what actually makes the thing easier to use. It is design by subtraction.
That is not how my instincts run. When you are excited about something you are building, the natural pull is to make every device capable of everything, as if that were the more generous option. It isn’t. It just makes the whole thing heavier.
I didn’t start building — I drew the finished picture first
With the roles settled, I wanted to jump straight into the real development. But Kuro made a suggestion.
Before you start building, how about we make a picture of the finished thing first? If you have a plan with the phone screen and the watch screen laid out side by side, everything after this gets a lot easier.
My first reaction was, honestly, “I’d rather build the actual insides than sit here drawing pictures.”
But there was more to the suggestion than I gave it credit for.
The first part is that you get to check the finished form with your own eyes. Being told in sentences that “the phone does this, the watch does that” is one thing. Actually looking at the two screens sitting next to each other is another — it lands in one go. “Ah, that’s what we mean.” And if something is off, you can say “no, not that” right there and fix it.
The second part turned out to be bigger than I expected: you stop having to give the same explanation over and over.
A plan on paper cuts down the explaining
When you are making something together with AI, the further the work goes, the more “we decided this earlier, remember” assumptions pile up. Spelling all of that out again in words, from the beginning, every single time, is a real chore.
But if you have one picture of the finished thing, you just hand it over and say “look at this,” and everything you already decided goes across in one piece. The role split, the arrangement of the screens, what sits where — the picture says all of it. You no longer need the long spoken explanation.
The plan is like a letter to future you. When you pick the work back up later, one look at this picture and you’ll remember straight away: right, this is what I was going for. And it saves you a big chunk of explaining time.
When I actually had the picture drawn, the “this is how I want it” that had been floating around in my head took on a clear shape. And if I save that picture, it becomes the starting line for the next time I sit down to continue.
Drawing before building looks like a detour. It was the shortest way through.
What I’m taking away from this
When you are thinking about an app that runs across more than one device, aiming for “everything can do the same thing everywhere” makes it more complicated, not less. Deciding first which device is the lead and which is the support leaves you in a far cleaner place.
And rather than starting to build straight away, draw the plan for the finished thing together with your AI first. With that in hand, there is less backtracking, and less of the effort that goes into repeating the same explanation.
Hold back the urge to build, just a little, and draw one picture. That small bit of extra work looks like it is going to make life a lot easier for the version of me who comes later.
If you want to see what happened when I did rush ahead and build, I wrote about putting an app prototype together in a single day. And the “stop explaining the same thing twice” idea runs much deeper than blueprints — that one is here.
