One codebase for a subscriber portal and a mobile app

Most internet providers arrive at the same place. There is a web cabinet where subscribers check their balance, written years ago against the billing system. Then a mobile app gets commissioned, usually from someone else, and it grows its own idea of what a tariff change means. Two codebases, two release cycles, and every new feature negotiated twice.

The costly part is not the duplicated screens. It is the duplicated understanding of the billing system underneath.

Where the divergence actually starts

A subscriber portal talks to billing constantly: balance, tariffs, promised payment, service suspension, outage notices. None of these are just reads. A promised payment has rules about when it can be requested, how often, and what happens when it lapses — and those rules live in the billing system, not in the UI.

When two clients implement them separately, they drift. The app allows a promised payment the portal refuses. Support gets a ticket that reproduces on one platform only, and now every conversation starts with "where did you see this?"

What sharing a codebase changes

With React Native Web, Next.js and Expo over one codebase, the rules are written once. The screens differ where platforms genuinely differ — navigation, notifications, biometrics — and stay identical where they should be, because they are the same code.

In practice this means:

• A feature lands on web, iOS and Android in one change, not three tickets.
• The billing integration has one implementation, so a fix is a fix everywhere.
• One person can maintain it, which for a provider with tens of thousands of subscribers is often the actual constraint.

It is not free. Shared code needs discipline about what belongs in the shared layer and what is genuinely platform-specific, and the answer changes as the product grows.

What it does not solve

It does not fix the billing system. If the API needs three calls to answer "what does this subscriber owe", you now make three calls from one place instead of six from two. That is an improvement in maintenance, not in architecture — and it is usually the next thing worth doing.