Why Our Web and Mobile Front Ends Share One Monorepo

Yes, the cover photo is a monolith. No, a monorepo is not a monolith. Mostly. Let me explain before the backend folks in UNA Builders come for me.

For the last few months I've been building a Next.js web front end and a React Native app that both talk to the same headless UNA install. For the first six weeks they lived in two repos. I fixed the same date-formatting bug three times: once in each app, and once more in a helper I'd forgotten existed. The third fix happened during a live demo. That was the end of two repos.

What lives where now

• apps/web: the Next.js site
• apps/mobile: the React Native app
• packages/app: shared screens, the API client and everything that talks to UNA
• packages/ui: design tokens and shared components

What got better

A change to the API client lands in web and mobile in a single commit, so the two can't drift apart. Dependencies are pinned once. Reviews are easier because the reviewer sees the whole feature instead of half of it in another repo. And CI only rebuilds what changed, so a typo fix in the docs no longer kicks off a 12-minute mobile build.

What got worse (the honesty section)

The first install is slower. Tooling config has become a small hobby of its own. And when the build breaks, it breaks for everyone, so we're now strict about never merging on a red pipeline.

Would I go back? No. Would I recommend it for a single UNA site with a custom theme? Also no, that's overkill. But the moment you have two front ends sharing logic, one repo saves real hours. Happy to walk through the setup at the next hackathon if anyone's curious.