React JS Development

Interfaces that stay fast as the product grows.

The interface is not the product

React is a way to build screens people click. It is not an order, a stock move, a GST invoice, or a permission model. Firms get hurt when a demo of a snappy table is treated as the system. The table still needs an API that tells the truth, a database that can be restored, and rules about who may reverse a dispatch. From Chengannur, LavisTech will build you a React front end when the job is an interactive application — a dealer dashboard, an admin your team lives in, a portal where state must stay consistent as the product grows. We will not sell React as a personality for five public service pages. That is a website. Websites want HTML a crawler can read, not a client router for Contact.

If anonymous visitors are the main users, you are in website territory. If signed-in users with different permissions are the main users, you are in application territory. Calling the application a “website” to make it sound cheaper is how you get a theme, a plugin for members, and a second project when two staff edit the same record. The line, and what it does to cost, is website versus web application. Read it before you let a framework preference rewrite a briefing. The user’s job decides the bucket. React is a tool inside the application bucket. It is a poor default inside the publishing bucket.

You still need an API — and someone who will own it

A React app that talks to nothing is a prototype. A React app that talks to a thin mock is still a prototype. Production means a server that checks roles, validates a payload, writes an audit line, and returns yesterday’s order without inventing it in the browser. That server might already exist. Then the React job is integration, error states, and screens that do not fall over when last year’s rows load. If the server does not exist, you are buying two jobs. Pretending they are one “React project” is how the pretty page ships and the desk still runs on WhatsApp.

We usually pair the UI with ASP.NET Core when the long-term cost is change you can make without a vendor’s permission, or with Laravel when PHP is already how the firm ships. Both can expose a clear API. Both can host the boring parts: login, backups, queues, a way to change a rate. React does not replace those. If a proposal lists component libraries and has no paragraph about the API, you have been quoted a skin. Ask who owns authentication, who writes the GST-sensitive totals, and what happens when the network drops mid-save. Those answers are the product. The spinner is not.

Component libraries that earn their keep

A component library is useful when the same control — a filterable table, a status chip, an upload with a progress state — will appear in twenty places and must behave the same when a junior adds a screen in month eight. It is waste when you wrap every button because a conference talk said “design system.” For an SME admin, we start with a small set: forms that show server errors in language a clerk understands, tables that survive real row counts, dialogs that cannot lose a draft on an accidental overlay click. We match the visual language you already have, or we keep it plain. Pretty that fights the warehouse phone is not a win.

Shared components also force decisions you would rather postpone: what empty looks like, what a permission denial looks like, how undo appears when accounts must see a reversal rather than a delete. Those decisions belong in the library because they belong in the business. A bag of npm cards with no rules will drift. Two dashboards will sort dates differently. A dealer will see another dealer’s price because someone copied a fetch. The library is not the brand PDF. It is the place those rules become hard to violate. If you do not have two or three screens yet, you do not have a library problem. You have a first-slice problem. Build the slice. Extract the third time you copy a pattern, not the first.

SPA versus a marketing site — do not invert the default

A single-page application earns its keep when the user stays signed in and moves through a job: create, correct, confirm, see today’s list. It is the wrong default for a public brochure. Search engines and first paint care about a document. A business site does not need a client router for Services and Contact. Ship the document. Enhance if you must. Do not invert that. We have watched firms buy a “modern React site” and then ask why the location pages are slow to appear and hard to rank. That failure is not a missing package. It is the wrong animal.

If you need both — a public site that ranks and a portal people work in — they can share a brand and a header. They still need two definitions of done, two hosting stories, and often two front ends that talk through an API. The public side is web development. The signed-in side can be React. Mixing them in one estimate is how the blog ships and the portal does not, or the other way around. Sharing a colour is not sharing a calendar. Write both jobs on the same brief so nobody “simplifies” them into one number.

What we will build, and what we will refuse

We will build admin dashboards, dealer or client portals, and design-system UI on top of a real API. We will take over a React app that already exists if we can see the source, the environments, and how it is released. We will not rebuild Tally in the browser. We will not put GST-sensitive totals only in the client and hope nobody opens the developer tools. We will not start from a blank “we need it in React” when the expensive assumption is still “staff will leave the spreadsheet.” That assumption is an MVP: one workflow, hosted, fail-able, with login, roles, undo, and a handover. A clickable Figma file is not that test. A private demo with dummy data is not that test.

We will also refuse to strip backups, roles, and undo to look lean. Cutting those to hit a date produces a prototype. Call it that and budget the next step. Do not call it an MVP and then wonder why nobody uses it. React makes prototypes look finished. That is a risk, not a feature. The Tuesday test is still the same: someone in the business completes the job without us in the room. “They liked the colours” is a prototype review. “Dispatch notes are created in the system four days out of five” is a result. Only the second one tells you whether to fund the next screen.

Pairing with ASP.NET or Laravel in practice

A typical shape we ship: ASP.NET Core (or Laravel) owns identity, the data model, and the API. React owns the screens that would be miserable as full page posts — live filters, multi-step jobs, optimistic lists that still reconcile with the server. Models are not “whatever the front end invented.” The server publishes a contract. The UI consumes it. When GST treatment changes, it changes in one place. When a role cannot see a salary PDF, the API refuses; the React tree does not “kind of hide” a button and call it security.

If your team already thinks in C#, ask whether you need a second language on the client at all. Blazor exists for that question, and it is the right default for many internal portals. React is the right default when you already have a JavaScript team, when you need a particular ecosystem, or when the UI density is the hard part and the API is already stable. We will say which side you are on after we have seen the job, not after we have picked a favourite conference. Honesty about that choice is cheaper than hiring two stacks because a slide said “modern.”

Time bands, without an invented total

If the API exists, the data is clean enough, and the first job is one workflow, a focused React slice is often eight to sixteen weeks: screens, integration, real-user testing, handover. If the API must be built, add that job — it is usually the larger one. A design-system extraction on top of a third or fourth screen is a short phase, not a platform programme. A public marketing site should not be on this estimate. Discovery of two to four weeks is the right buy when the brief is still “make it like the app we showed you on our phones.” We will not print a rupee figure that will be wrong for your payment gateway, your Tally connector, or the mess of your item codes.

What drives the number is the same as any custom work: integrations, roles, data quality, and how finished “done” is. Five roles that must not see each other’s records is a design problem, not a checkbox. Migrating ten years of Excel with duplicate customers is a project of its own. A demo on a laptop is not hosted, backed up, with a way to change a rate without calling us. If two vendors differ by a factor of three on the same one-page brief, one of them has not priced the API, the migration, or the handover. Ask them to show which. Plan a day a week from an operations lead. React will not learn your exceptions from a mood board.

How a first slice should read on a purchase order

Write the expensive assumption as a sentence. “Dealers will raise a claim here instead of email.” Then write the in-list: login, create a claim against an order, attach the photo they already take on WhatsApp, see status, undo a mistake, export for accounts. Write the out-list: customer marketing pages, last year’s analytics, a mobile store listing, bilingual help. Write who will use it on Tuesday without us. Write what you will count after two weeks. If a director adds an item, something leaves or the date moves. A React MVP with a growing first list is a full project in denial.

Week one is not a component library. It is sitting with the people who do the job and writing those two lists so narrowly they feel rude. Week two is access: test accounts, a sample of real data, API credentials someone must request. Weeks after that are one path that works on real records. If after a month you have only workshops and a Figma file, you do not have a software partner. You have unnamed discovery. That can still be useful. Do not pay build rates for it. If this is the conversation you want, bring the unofficial list and the API you already have — or the admission that you do not — on the contact page. Do not send a Dribbble link and call it a brief.