A companion web app is the browser-side surface of a product that lives primarily in a mobile app: the place where a customer signs up before installing, where a shared link opens for someone without the app, where work started on a phone continues on a desktop. It is the same product, on the same API, shaped for what a browser is actually good at, rather than a port of the app or a brochure about it.

Most agencies build one side or the other. We ship Flutter apps, web frontends, and the backend services both consume — which changes the engineering, because the question "which surface should this feature live on" gets answered by one team looking at one system, not negotiated across two contractors.

The products we build

  • Customer web apps alongside mobile apps — the full product in the browser where that makes sense, or the deliberate subset where it does not
  • Public, shareable surfaces — the pages a shared link resolves to, rendered and indexable, that hand off into the app when it is installed
  • Real-time web clients — live data in the browser from the same feed the apps consume
  • Back offices for the same product — the operator-facing side is its own discipline, covered on admin panels & dashboards
  • The web side built on Nuxt — when the companion surface must rank, the machinery is our Nuxt development practice

Who Builds Your Companion Web App

Two products in production show the pattern, each with an app and a web surface sharing one backend.

Formtastic — one platform, three clients

Formtastic runs as a Nuxt web application plus Flutter apps for iOS, iPad, and Android, all against the same Django and Go backend. The instructive part is how features land differently per surface: voice-to-text on the web records audio in the browser and sends it to a transcription endpoint, because a backend was already there to extend — while the mobile apps bundle Whisper on-device, because job sites have no signal. Same feature, two implementations, each honest about its surface. That judgment, more than framework skill, is what a two-surface product actually requires.

ExtraETF — one real-time feed, every client

For ExtraETF, we built the Go service that broadcasts live market data to both web and mobile clients — thousands of simultaneous connections, updates conflated to the cadence a human watching a price actually needs. We built the mobile apps and the real-time layer; the web client consuming it belongs to the client's own team — which is precisely the point. A well-designed service feeds surfaces you will never build yourself.

What a Two-Surface Product Actually Demands

Four disciplines keep an app and a web surface from drifting into two products.

One API that serves both honestly

The moment the web needs "just one special endpoint," you have two backends wearing one name. We design the API as the product's single contract — the same authentication, the same models, the same versioning for every client — and where the surfaces genuinely need different shapes of data, that difference is written into the contract rather than patched into a client.

Deciding what the web version is

The expensive mistake is "the app, but in a browser." A companion surface earns its budget by doing what the app cannot: being reachable from a search result, opening instantly from a shared link, offering a keyboard and a big screen for heavy editing. We scope the web surface feature by feature against that test — and cutting a feature from the web version is a decision we will argue for out loud, not a gap discovered later.

The handoff between web and app

A shared link should open the app when it is installed, the web page when it is not, and never a broken interstitial. Universal links on iOS and app links on Android, the fallback pages behind them, and the sign-up flow that starts in a browser and continues in the app — this seam is where two-surface products most visibly leak users, so we engineer it deliberately instead of assuming it works.

Rendering matched to the page's job

The public, shareable pages render on the server so crawlers and link previews see real content; the logged-in workspace behind them renders like the application it is. The trade-offs are laid out on the web development pillar, and the choice is per route, not per project.

How We Work

Fixed-scope build. We take the web surface from feature scoping through deployment, against your existing API or one we build alongside it.

Staff augmentation. Our engineers join the team that owns the product — see team augmentation. If the mobile side needs building too, that is our Flutter practice.

Either way, we send a scoped quote within two business days of understanding the requirements.

What a Companion Web App Costs

A companion surface is priced from the same published tiers as the web development page: an authenticated web app on your existing API sits in the web app tier at $15,000 – $40,000, while a full second surface with real-time features, payments, or multi-tenant structure prices as SaaS-grade work from $50,000+.

These are the same keys that render the pillar's pricing table, so the two cannot drift. What moves the number: how much of the API already exists and how cleanly it was designed for more than one client, how much of the product the web version covers, and whether real-time features ride an existing feed or need one built.

Frequently Asked Questions

Common questions from teams whose product lives in an app and keeps being asked for in a browser.

Not always — and the honest answer depends on where your growth leaks. A web surface earns its budget when sign-ups start from search or shared links, when users ask to work on a big screen, or when every shared piece of content currently dead-ends for people without the app. If none of those apply, we will say so; a well-made store listing and deep links may be all the web presence you need.
Usually not, and deciding what to leave out is most of the scoping work. The browser wins at reachability — search, shared links, instant access with no install — and at keyboard-and-big-screen work; the app wins at camera, offline, notifications, and being one tap away. Formtastic's voice-to-text is the pattern: the web records in the browser and transcribes on the server, the apps transcribe on-device because job sites have no signal. Same feature, different honest implementations — and some features rightly stay app-only.
We build against existing APIs routinely — Formtastic's web frontend runs on the Django backend the product already had, extended where the web needed it. What we will do first is assess whether the API is genuinely multi-client: authentication a browser can use safely, models that do not assume app-only flows, and versioning that lets two clients evolve. Where it falls short we tell you precisely what to change, and can do both sides ourselves when that is faster.
Yes — that is a feed design question, not a framework question. For ExtraETF we built the Go WebSocket service that broadcasts live market data to web and mobile clients alike, holding thousands of simultaneous connections and conflating updates to roughly one per instrument per second, the rate a human actually needs. Design the real-time layer once, correctly, and every current and future client consumes the same stream.
Through universal links on iOS and app links on Android: the same URL opens the app when installed and the web page when not, with the web page carrying the full content rather than an install nag. Done right, the link also survives installation — someone who lands on the web, installs the app, and opens it arrives at the content they were promised. This handoff is where two-surface products lose the most users, so we treat it as a feature with its own engineering budget.
An authenticated web app on an existing API typically runs 15,000 to 40,000 US dollars over one to three months — the published web app tier on our web development page. A full second surface with real-time data, payments, or multi-tenant structure prices as SaaS-grade work upward of 50,000. The biggest lever is your API: one designed for multiple clients keeps the web build lean, while one assuming app-only flows adds backend work we will scope explicitly.

See both surfaces in the Formtastic case study, read how the ExtraETF real-time feed fans out to every client, or start from the web development pillar.