Blazor Development

One .NET team, from API to screen.

One C# team, from the API to the screen

Blazor is interesting to a Kerala SME for a boring reason. If your business system is already going to live in .NET — orders, stock, roles, a Tally posting — you can keep the same language on the screen. Models do not get retyped into TypeScript and then slowly drift. The person who wrote the GST-sensitive total can see the page that displays it. LavisTech works that way from Chengannur when the honest job is an internal portal, an admin your staff will live in, or a signed-in tool where the hard part is the rules, not a consumer-grade animation. We are not selling a religion about JavaScript. We are selling a smaller team that can change a field in one place.

That advantage disappears if you pretend Blazor is a way to avoid thinking about the web. You still need hosting, identity, backups, and a definition of done. You still need someone who understands that a clerk on a warehouse phone is not a developer on a fast office network. You still need an API or a clear server model; Blazor does not make Excel into a database. What it does make is a path where a C# shop does not hire a second stack to draw a form. For many of the systems we are asked to replace — job cards, branch stock, a dealer claim screen — that path is enough.

Blazor Server versus WebAssembly — pick for the room, not the blog

Blazor Server keeps the UI logic on the server and pushes diffs to the browser over a persistent connection. It starts quickly, keeps secrets and heavy work off the client, and fits offices where you control the network well enough. It goes wrong on flaky mobile links, when every keystroke should not need a round trip, or when you need the tab to survive a dropped connection without drama. Blazor WebAssembly ships .NET to the browser. It can work offline-ish once loaded, and it moves CPU to the client. It pays for that with a heavier first load and a larger hosting story. Neither is “the modern one.” Each is a trade.

For internal portals on a desk — accounts reviewing a posting, a supervisor closing a job, a clerk entering an order — Server is often the first honest choice. The users are known, the network is known, and you want the server to remain the authority. WASM becomes interesting when you need richer client behaviour, a more app-like feel after load, or a hosting shape that does not keep a circuit open for every open tab. We will not pick WASM because a talk said Server is old. We will not pick Server because it is easier to demo on our office wifi. We will ask who is holding the phone, and what happens when the link dies mid-save. Undo still matters. A silent retry that duplicates a dispatch does not become acceptable because the framework is .NET.

Internal portals are the honest win

The jobs Blazor is good at look like this: a signed-in user completes a workflow the business already has; roles matter; yesterday’s record must be findable; the screen can look like software rather than a brochure. Staff already tolerate a login. SEO does not apply behind that login. You can spend the budget on permissions, audit, and a parallel run against Tally instead of on first-paint theatre. That is the opposite of a public marketing site, and it is most of the work growing firms actually need. A branch tool for stock transfers. A back-office for bookings. A dealer screen for claims and a price list that must not leak between dealers.

WhatsApp and Excel are usually the systems we are replacing, not SAP. If the portal does not beat the group on a busy Thursday, staff will keep the group. Blazor will not save you from a missing undo, a slow search, or opening stock nobody counted. The framework is how we draw the screen. The product is whether the night shift completes the job. We still photograph the unofficial workbooks first. We still write a first-slice sentence. We still refuse to rip out Tally on day one so the new pages can “do GST.” Those habits are the same as any other business system we ship. Blazor is just the UI that lets a .NET team stay one team.

The wrong default for a public SEO site

Public pages want clean URLs, fast first paint, and HTML a crawler can read. That is a website problem. Blazor can publish pages. It is still a poor default when the main users are anonymous visitors who want a phone number, Saturday hours, and a service page that ranks. A WASM download before the copy appears is how you lose the visitor and the crawler. A Server circuit for a brochure is a hosting bill in search of a reason. If you need a public site and a portal, they can share a brand. They should not share one “Blazor website” quote. The distinction is the same one on website versus web application. Marketing URLs and app URLs want two definitions of done.

We rebuilt our own public site as ASP.NET because the job was publishing, not a staff workflow. That is still a website: pages, knowledge, contact, an admin login that is not the product. We did not make it a Blazor SPA to look current. If a vendor proposes Blazor for five service pages and a blog, ask them what Google is supposed to index on the first request, and who is paying for the circuit when nobody is logged in. If they cannot answer without a slogan, keep the brochure on ordinary server-rendered pages. Use Blazor where people work.

Which job we do first

First job is never “adopt Blazor.” First job is the sentence you are most unsure about. “Warehouse staff will record dispatches here instead of WhatsApp.” Then we choose the hosting mode that fits those people, and we build only what the sentence needs: login, create a dispatch against an order, print or send a note, today’s list, undo, export for accounts. Not in the first slice: a customer marketing site, route maps, last year’s charts, a driver store listing. If a director adds those in week three, show the two lists and ask which week moves. That conversation is the project. The framework is how we test the sentence.

If the team is already C# and the users are staff, we start in Blazor — usually Server — unless the phone network makes that cruel. If the API already exists and a JavaScript team already owns the client, we will say so and point you at React JS development instead of inventing a second UI stack for pride. If there is no API and no data model, the first job is .NET development of that model, not a debate about render modes. Screens without a source of record are theatre. We have no interest in theatre that survives a demo and dies on Tuesday.

Shared models, and why they are the point

The pitch for Blazor that matters in year two is not a benchmark chart. It is that the object an API returns can be the object a form binds, with validation attributes that mean the same thing on both sides. Item codes, GST fields, and “this role cannot see this branch” stay in one language. You still design the contract on purpose. You do not spray entities at the browser and call it architecture. You still decide what a dealer may see. Sharing a model is not sharing every column. It is refusing to maintain two slightly different truths about an invoice line.

That discipline also helps handover. A small SME team can change a rate or a required field without convening a front-end ceremony. Source you own is worthless if only one contractor understands the TypeScript half and they are on another project. We still write how to release, how to restore, and how to change a connection. Blazor does not remove operations. It removes a common excuse for a second undocumented app beside the first. If after go-live people export to a spreadsheet to “do the real work,” you have a reporting skin in C#. We will call it that. The language did not save you.

Time, hosting, and the boring parts we will not cut

A focused internal portal — one login, one workflow, hosted, handed over — is often eight to sixteen weeks when the integrations are few and the item list is clean enough. Discovery of two to four weeks is the right prior buy when the brief is still a paragraph. A fuller operations tool that talks to Tally and a second branch is a longer, phased programme, the same as any business system. Azure is a common home for this work; it is not a requirement, and it is not a strategy. Hosting, backups, SSL, and who gets the bill when the site is live belong in the quote. A cheaper build that omits them shows up as an emergency in month two.

We will not print a rupee total that will be wrong for your weighbridge, your GST exceptions, or your opening-stock mess. We will not lock twelve modules to a festival date on a first call. We will not strip login, roles, backups, or undo to look more like an MVP. Those boring parts are what let you leave the tool with staff. A WASM demo on a laptop with dummy data is a prototype. Say the word. Budget the next step. Parallel run still applies when money or stock is involved: both paths for a named stretch, a shrinking mismatch list, then a management act to switch the old path off. Blazor cannot retire a workbook people still trust.

A purchase-order sentence, and when to walk away

Paste something this narrow: one team; one job; Blazor Server unless we write why WASM; yesterday’s record findable; Tally stays for a phase if that is the honest split; parallel run if the job touches stock or invoices; no public SEO site in this number; source and hosting handed over; a named week of support. If a vendor deletes the parallel run to look faster, they deleted the phase that makes the months real. If you cannot name the team and the job, you are not ready for Blazor. You are ready for a workshop. If the main users are anonymous visitors, you are ready for a website, not this page.

Walk away from a brief that is “rewrite the company in Blazor” with no sentence. Walk away from a public-site rewrite sold as modern .NET when the pages only need to rank and convert. Walk away from a fixed price before anyone has seen an export. We would rather lose that work than win it and spend a year discovering that two branches do not share item codes. If the sentence exists, bring the unofficial workbook and the systems that must stay — Tally, a scale, a site — on the contact page. Say which job is first. We will tell you whether Blazor is the right UI, or whether you need the API first, or whether you should buy a product and keep the week.