A mobile app is not a smaller website

A mobile app is easy to underestimate if you have been building for a browser. The screens are narrower. The navigation is a stack instead of a row of links. It is tempting to treat that as a layout problem and reuse the same flows, the same requests, and the same idea of a session. The phone will tell you that was wrong, usually in the first week people actually install it.

I learned that on Butter, a video product. I co-built the mobile MVP with one other person. It reached about 5,000 downloads in the first month, and passed 20,000 after that. We also shipped a lot: more than twenty-five features and several larger updates inside six months. The pace was only possible because we stopped pretending the app was a website with a different frame.

The first difference is that the user does not sit and wait the way they sometimes will on a laptop. A screen that fetches three things in sequence, then lays out, then fetches again because a child component mounted, feels broken in the hand even when the same sequence is tolerable in Chrome. I spent real time on that, not on new gestures. Chat was the sharp edge. A conversation that jumps, duplicates a message, or loses the bottom of the thread feels unreliable, and people leave a video product that feels unreliable. Stability of that one surface mattered more than another setting screen.

The second difference is the release. A website deploy is yours. An app release goes through a store, a review, and a user who may not update today. We could not treat every fix as something that would be on every phone by tomorrow. That changes what you put in the build. A bug in a path everyone hits has to be rare, because you cannot silently replace the binary the way you replace a tab. Feature flags and small releases helped. So did saying no. Six months of constant updates is only sustainable if each one is a thing you can explain and roll forward, not a rewrite you hope the store approves.

Performance on a phone is also more physical. Jank is something you feel with your thumb. I have made the mistake, earlier in my career, of blaming the framework for lag that was really three slow requests and a state update on every one of them. By the time I was shipping this app I was more interested in what the screen asked for, and how many times it rendered before it had a stable answer. React Native was not the thing to swap out. The work was the same work as on the web: fewer surprises between an action and the next frame.

A two-person team cannot carry a separate mobile architecture and a separate web architecture that disagree. Shared types, a shared idea of the account, and a backend that does not care which client is calling will save you. What does not carry over is the interface. A desktop layout squeezed until it fits is still a desktop layout. The phone needs a path with fewer steps, larger targets, and a recovery when the network drops mid-action. I would rather ship fewer screens that survive a tunnel than a full copy of the website that falls apart on the train.

The download count is a vanity number if people do not come back. The part I care about is that the app kept moving after the first month: fixes, features, and a release someone on the team could ship again. That is the bar I still use. A mobile product is finished when a person can hold it, lose the connection, come back, and find the same conversation where they left it.