My stack for a mobile app, working alone

This is the stack behind CalAlly, the voice based nutrition tracker I am building. Under the hood it is the same as the one I use for a web app, and only the piece that draws and delivers the interface changes.

Eight tools: two specific to mobile and six that stay identical. Them being identical is not a coincidence, it is the point: if I had needed to learn a new backend to make an app, the app would not exist.

The two pieces that make it an app

React Native: one codebase for iOS and Android. Alone, maintaining two native apps is not an option, so the question is not whether native is better, because it is: it is which of the two apps I could realistically keep up to date. The honest answer is neither.

There is a second reason, less noble and more practical: React Native is React. The mental model of components and state is the one I already use on the web, so moving between projects does not cost me a change of head.

Expo: the part that makes React Native manageable for one person, and the part I underestimated before trying. The app code is the easy bit. What eats the days is everything around it: builds for two platforms, certificates, provisioning profiles, versions, store uploads.

Expo takes that piece and reduces it to a command. More importantly it lets you ship updates without going through store review every time, which alone is the difference between fixing a mistake in half an hour and fixing it next week.

The six that are already the web ones

This is where repeating the same stack across three projects actually pays: when I started the app, half of it was already decided.

Supabase: database, auth and storage. On mobile one thing matters more than on the web: access rules live in the database, not in the client. An app gets installed on somebody's phone, and any check written only inside the app is a check that can be worked around. With rules at the database level the surface shrinks to a single place.

Resend: transactional email. Confirmations, password resets, anything triggered by an action in the app.

PostHog: product analytics. It matters more here than on the web, because you cannot watch somebody use the app over their shoulder: the only thing telling you whether a screen landed is behaviour.

Featurebase: help centre and feedback. In pre launch with testers it is the tool I use most, because it holds requests and reports in one public place instead of twenty separate messages.

Namecheap: domains. An app needs one too: a page explaining the product, store links, and the privacy policy the stores ask for, which has to live somewhere.

GitHub: code and history, same as everything else.

What actually changes between web and mobile

The code, less than I expected. Everything else, quite a lot.

• Shipping is no longer yours. On the web you publish when you want. On the stores there is a review in the middle, and it belongs in the plan rather than being discovered at the first rejection.
• Old versions stick around. You update a site for everyone at once. An app you do not: somebody is still on the build from two months ago, so the backend has to keep answering that one too.
• You see nothing without analytics. On the web I have server logs and Search Console. On an installed app, without instrumentation you are blind.
• The first user costs more. Opening a link is free, downloading an app is not. It is why the page explaining the product matters even more than on the web.

What I do not use, on purpose

• No push notifications in the first version. They are the thing everyone adds first and almost nobody has earned. Until I know what brings people back, a notification is just a way to get uninstalled.
• No heavy component library. Same reason as the web: alone, the debt hidden in a dependency costs more than the extra line.
• No subscriptions before understanding what is being paid for. In app payments come with rules, fees and edge cases you do not want to learn while still working out whether the product is useful to anyone.