A delivery service has a Flutter courier app and needs an admin dashboard and public order-tracking pages; which would you build with Flutter web, and which as a separate web app?
answer
- app-centric vs document-centric
- behind a login, search does not matter
- shared Dart models and logic
- first paint for anonymous visitors
- browser features a canvas lacks
basics
~20 sThe admin dashboard suits Flutter web: logged-in, app-like, used on desktop, able to share Dart code with the courier app. Public tracking pages need fast first paint, link previews and search, so they fit a lightweight HTML page.
solid answer
~50 sI would split by the kind of surface. The **admin dashboard** is app-centric: staff sign in, sessions are long, the download is cached after the first visit, SEO is irrelevant, and it can reuse the courier app's models, validation and API clients in Dart. Flutter web fits, with path URLs and an index.html rewrite, `HtmlElementView` for any web-only widget such as a map SDK, and a check that data-heavy tables, text selection, browser find and keyboard use meet the team's needs. The **public tracking page** is document-centric: anonymous visitors arrive from a link on a phone, want the status in about a second, and the link should preview in chat apps. A small server-rendered or static HTML page does that better than downloading a renderer and a compiled app. Share the API contract, not the UI. A team with no web skills might still choose Flutter for both.
go deeper
Recall that Flutter web suits app-like surfaces and struggles with search-driven, document-style pages.
Explain which properties of a surface, such as login, device, first paint and SEO, point toward Flutter web or HTML.
Show the checks you would run before committing the dashboard to Flutter web: text selection, find, accessibility, embedded SDKs and hosting headers.
Frame the choice per surface with explicit criteria, share the contract rather than UI, and state which team or product changes would reverse the decision.
## The question behind the question "Flutter web or a separate web app?" is rarely all-or-nothing. The useful move is to classify each surface by what it needs, then pick the technology per surface. The Flutter web FAQ gives the frame: Flutter web suits **app-centric** experiences such as single-page apps, PWAs and existing Flutter mobile apps, and does not suit **document-centric**, text-rich content where the web's document model shines. ## The two surfaces | Need | Admin dashboard | Public tracking page | |---|---|---| | Users | signed-in staff, long sessions | anonymous customers, one visit | | Device | mostly desktop browsers | mostly phones from an SMS or email link | | First paint | a one-off cost, then cached | the whole experience | | Search and link previews | irrelevant | useful: link previews, maybe search | | Code shared with the courier app | models, validation, API client, some widgets | the API contract only | | Interaction density | high: filters, tables, maps, dispatch actions | low: status, map, contact button | ## Why Flutter web fits the dashboard - **Code sharing.** The courier app's Dart models, validation rules, API client and state logic compile for the web unchanged, so dispatch rules stay consistent. - **App-like UI.** Dense interaction, keyboard shortcuts and custom visuals are Flutter's strengths, rendered identically in every browser. - **The download is amortised.** Staff load it once per release; caching makes later visits quick. - **SEO is irrelevant** behind a login. What to check before committing: 1. **Browser expectations.** A canvas-rendered app does not give browser find-in-page, and text is selectable only inside `SelectionArea` or selectable widgets. Staff who live in data tables will notice. 2. **Accessibility.** The semantics DOM is opt-in on the web; turn it on with `SemanticsBinding.instance.ensureSemantics()` if staff use assistive technology. 3. **Third-party web widgets.** A map or charting SDK that exists only for the web goes in an `HtmlElementView`, with its pointer-event and overlay costs. 4. **Hosting.** Path URLs need an `index.html` rewrite; Wasm threads need COOP and COEP headers, which can clash with embedded third-party content. ## Why HTML fits the tracking page - A customer taps a link on a phone and expects the status at once. A small HTML page renders on arrival; a Flutter web app must first fetch its renderer, compiled code and fonts. - Messaging apps build link previews from HTML meta tags, which a static or server-rendered page can fill per order. - On iOS every browser is WebKit, so the Flutter app would run its JavaScript build with CanvasKit, never the faster Wasm path. - The page is simple enough that sharing Flutter widgets saves little. ## What stays shared Share the **contract**, not the UI: the same backend API, the same status vocabulary and, if useful, an OpenAPI or JSON schema from which both the Dart client and the web page's client are generated. Brand colours and icons can be exported as design tokens for both. ## When the answer changes - **A small team with no web skills** may reasonably build both in Flutter and accept a slower tracking page, perhaps with a plain-HTML status line in `index.html` shown before Flutter loads. - **A dashboard that must be embedded** in an existing web portal can run Flutter inside a host element through embedded or multi-view mode, instead of owning the whole page. - **Heavy text and reporting**, such as long printable reports, may push the reporting part toward HTML even inside the dashboard. A strong answer names the criteria, applies them per surface, and says what would change the decision.
- Operations staff complain they cannot use Ctrl+F or copy order numbers in the Flutter web dashboard. What do you change?Wrap text-heavy areas in `SelectionArea` so text becomes selectable and copyable, and add an in-app search field over the loaded data, since browser find-in-page cannot see canvas-rendered text. If staff rely on exporting large tables, offer CSV or an HTML report view as well.
- The business later wants the tracking page to feel like the app. Does that force Flutter web?Not necessarily. Share design tokens, icons and the API contract so the HTML page looks consistent. If richer interaction is needed, embed a Flutter view into a host element of the HTML page, keeping the status text and meta tags in HTML for fast first paint and link previews.
saying these in an interview costs you the question
- Flutter web is right for every surface once the mobile app is in Flutter.
- Flutter web is never acceptable for production web apps.
- Code sharing means the tracking page should reuse the dashboard's widgets.
- SEO matters equally for a logged-in dashboard and a public page.
- Browser find-in-page works on Flutter web text by default.