One codebase, five surfaces
Most software that runs in the browser, on the desktop and on phones is really three products wearing the same logo. Three codebases, three backlogs, three versions of every bug. We build it as one system.
This page explains the architecture in plain terms: what it is, what it buys, what it costs, and where it is the wrong choice. We build and operate our own product on it, so nothing here is theoretical.
The architecture
Every screen, control and rule of the interface is written once, as a shared library of Razor components on .NET. That one library then ships into five different render contexts. The components do not know which context they are running in, and mostly they do not need to. That is the whole trick, and it is also where the risk lives.
The server renders the HTML and streams updates to the browser over a persistent connection. First paint is fast because the browser downloads markup, not a framework.
The same components compile to WebAssembly and execute inside the browser itself. After the handoff, the interface runs on the user's machine instead of round-tripping to the server.
A native desktop application hosts the same components in an embedded web view. It installs, updates and behaves like a Windows app because it is one.
The same pattern on iPhone and iPad: a native shell built with .NET MAUI, hosting the shared components, distributed through the App Store.
And the same again on Android. One more native shell around the same library, distributed like any other Android app.
The trade
A business rule lives in exactly one file. When it is wrong, you fix it there, and the fix ships to the browser, the desktop and both phone platforms in the same release. There is no second implementation to drift, no port lagging two versions behind, no meeting to reconcile what the iPhone app thinks with what the website knows. One codebase means one truth.
The five render contexts are not identical, and the failures between them are quiet. A component can work on the web and silently do nothing on a device: the markup renders, the button just never responds, nothing crashes, nothing logs. The only defense is discipline. We treat "works in one context" as untested.
Firms selling this kind of architecture like to quote a code-reuse percentage. We will not. The number depends entirely on what you choose to count, which makes it advertising, not measurement. Here is the claim we can stand behind: the interface and the rules behind it are written once, and what gets written per platform is the thin native shell that hosts them.
The stack
Naming the actual technology is a courtesy to whoever has to evaluate us. This is the stack our own product runs in production.
.NET, across server, browser and device.
Blazor, in Hybrid and Auto render modes. The same Razor components serve every surface.
.NET MAUI. The host application on Windows, Apple and Android devices.
Azure SQL. Boring in the way a database should be.
SignalR. State changes push to every connected screen without polling.
Azure DevOps. Source control, the work item board, and the pipeline that deploys on merge.
Playwright. Automated end-to-end tests that drive the product the way a user does, not the way a unit test wishes they would.
The counterexample
The page you are reading is static HTML, generated at build time, with zero client-side script. No framework, no hydration, no loading spinner. It is nothing like the architecture described above, and that is the point.
A marketing page has no live state to synchronize and no signed-in user to serve. Shipping an application runtime to display paragraphs would make the page slower and prove nothing. The right tool for a marketing site is not the right tool for an application, and a firm that reaches for the same hammer on every job is not thinking.
Next
MyEventBingo is our own product, built and operated on exactly this architecture. We wrote up how it works. If your project needs one system on every screen, that is an engagement we take.