.NET Development

Powerful software built around your business.

What .NET is for in a firm like yours

.NET development here means line-of-business software people log into and finish a job in — portals, APIs, the operational middle that sits between Tally, Excel, and the WhatsApp group. It is not a lecture about frameworks. It is not a rewrite of your public brochure. If anonymous visitors are the main users, you want a website. If signed-in staff, dealers, or customers are the main users, you are in this service even when the screen is a browser tab.

We build this from Chengannur for SMEs that already run on a ledger, a stock book, and a few people who know how the week actually starts. The useful system is the one that replaces a sheet without inventing a new religion of work. ASP.NET Core is how we usually do that: one backend, SQL Server when the data must last, roles that are not a shared password, and a handover you can restore on a bad Monday.

Portals and APIs, not a technology brochure

A portal is a place with a login where a known person does a known job: raise a claim, see a dispatch, approve a leave, upload a document, confirm a quantity. An API is how that portal — or a phone screen, or Tally, or a website — gets the facts without someone retyping them. Most of the work is not the screen. It is agreeing which system is the record, who may change it, and what happens when two people edit the same row.

If the job already lives in a package you pay for, we would rather configure that package or talk to its API than invent a second database of the same orders. Duplicate records are how Friday disappears. Custom earns its keep when the product cannot express how you bill, stock, or job — the operational middle — and staff already keep a workbook to fill the gap. That is the custom versus off-the-shelf line. Read it before you fund a platform.

Line-of-business that replaces the unofficial Excel

Every growing firm has a sheet that is “just for this month”. Month six it is still there. It holds the truth the official system does not: the real rate for that dealer, the job that is waiting on a part, the GSTIN that Tally almost has. The first .NET slice should attack one of those sheets with a sentence you can test: “dispatch notes are created here four days out of five.” If you cannot write that sentence, you do not have a build yet. You have a wish list.

We will sit with the person who currently owns the sheet. Not a steering committee of eight. If they cannot spare two hours a week, we will encode guesses and they will ignore the result. The sheet stays. That is not a technology failure. That is a briefing failure.

Branch books matter. If two locations count stock differently, software will not settle the argument. It will make the argument faster and harder to see. Write the rule on one page before anyone opens Visual Studio. Two people, separately, then compare. Where they disagree is the project.

When Blazor and when React

This is a staffing and ownership question, not a fashion question. Choose Blazor when the same .NET team should own the API and the screen, the users are mostly internal or a controlled portal, and you do not want a second JavaScript pipeline for every small change. Choose React when you already have a front-end practice, you need a rich public interface that will grow for years, or the API must serve more than one client — a site, a store listing, a partner.

Both can talk to the same ASP.NET Core API. Mixing them in one product because two demos looked pretty is how you pay twice for the same form. We will pick one for the first slice and write why. If a vendor leads with the framework and never asks who will maintain the screen in year two, you have a brochure.

Internal tools that look like admin — tables, filters, a confirm, an undo — are where Blazor Server often earns its keep: fast to ship, one language, hosting you already understand. Customer-facing flows that must feel like a modern site on a phone may still want React, or they may want ordinary Razor pages if the interaction is a form and a status. Do not buy a single-page app to display a PDF and a button.

Tally, SQL Server, and the systems that already exist

Tally is the ledger for a large share of Indian SMEs. We do not replace it for sport. We read from it, we write the few events it must own — a bill, a receipt, a stock journal — and we keep the operational middle in SQL Server where you need history, roles, and reports Tally was never meant to be. If your “integration” is a CSV someone emails on Friday, say so. That is a different estimate from a live API you do not control.

SQL Server is the default when the data must survive a person leaving and a backup must be restorable. Excel is a workshop, not a system of record. If the first slice only needs a few thousand rows and one office, we can start smaller — but we will still tell you when the sheet is about to become the product. GST fields, HSN guesses, and round-off fights belong in the brief. They are not “phase two polish”. They are why accounts will refuse the tool if we pretend they are optional.

WhatsApp is not a database. If the night shift already dumps job photos into a group, the first slice may be “the job file is created in the system, and the group only gets a link”. Closing the group is a management sentence. Software cannot retire a chat. A supervisor can. Put that sentence in the statement of work or the build will be done and unused.

Roles, backups, undo — the parts that make it software

Roles are not “admin and everyone else”. They are who may see a price, who may post a bill, who may reverse a dispatch, and who may only look. Shared logins make those sentences false. We will refuse a go-live that still uses one password on a wall. If that sounds stubborn, picture the week after someone leaves and the wall is still there.

Backups you can restore are part of the definition of done. A host that “takes snapshots” is not a restore you have practised. We write the restore steps in the handover and we expect you to name who runs them. Undo matters more than a pretty dashboard. The bay will accept a firm reversal. They will not accept a silent change. Accounts will not accept a delete. The screen is how those two constraints meet: a history on the record, a reversal that looks like a reversal, and a role that cannot rewrite the past.

If your first slice cut undo and roles to hit a date, you shipped a prototype. Call it that and budget the next step. Do not call it an MVP and then wonder why the spreadsheet stayed. An MVP still includes login, roles, backups, and a way to undo. Cutting those to look faster produces a demo staff will not keep.

What a first slice looks like

One workflow, real users, a written definition of done, on devices they already have. Login, the happy path, the three exceptions that already happen every week, a log, backups, a named week of support. Out-list beside the sentence: customer portal, last year’s reports, the second branch, an AI draft button — whatever was wished on Monday and did not survive Thursday. An MVP without an out-list is a full project in denial.

Eight to sixteen weeks is a common band for that shape when the systems you talk to already have a way to talk. Two to four weeks is discovery or a thin prototype you will throw away or keep on purpose. Four to nine months is several sheets and two integrations, phased, not a single heroic launch. We will not print a rupee total that will be wrong for your Tally edition. The estimate shape — scope, assumptions, change process — is on how much custom software costs.

Parallel run is not optional if money or stock moves. A week where the old sheet and the new screen must agree, with someone who will look at the mismatches. If nobody will look, you do not have a go-live. You have a demo next to the real office.

Integrations that are the project

Talking to Tally, a payment gateway, an SMS provider, or a legacy Access file is often most of the calendar. The screen is the small part. Bring the edition, the licence constraints, a sample export, and the person who already fights that system on Friday. If there is no API, the work is a file drop, a desktop bridge, or a honest “not this year”. Pretending there is an API because a brochure said “connects with Tally” is how week six moves.

Identity is an integration too. If people already have Microsoft 365 or Google Workspace, we can use that instead of a new password they will write on a sticker. If they do not, we will still not ship a shared account. Password reset that works on a phone is part of the first slice, not a later nice-to-have.

Handover and the two in the morning call

You get the source in a repo you own, the database backup steps, the hosting in an account you control or a written transfer, environment notes, and a one-page “how we release”. Secrets do not live in a chat history. If we used Azure or a VPS, you get the map of what is running. A week of support after go-live is normal. An unpaid second product is not.

Who gets the late call must be named — us on a retainer, your IT person, or a host who only reboots. Applications need a person who can roll back a release. Marketing sites can live on simpler hosting. Do not put both on the same cheap shared plan and hope. If you are not sure which you are buying, say so in the brief. We will tell you.

When we will tell you not to build

When a product already does the job and staff can live with the twenty percent it misses. When two people cannot describe the same process. When the only owner is leaving in June. When the request is “make the office faster” with no timed step. In those cases the useful spend is a short systems review or a workshop, not a solution template. The prior question — build, buy, or hybrid — is should I build custom software or buy. Use it. Do not skip to a framework because a demo was smooth.

We would rather lose a project at that point than encode a mess and get blamed for the mess being faster. That is not a slogan. It is how we stay in this town.

What we will not do

We will not start from a module brochure and retrofit your week into it. We will not hide Tally as “phase two” if accounts already said the bill must post. We will not cut the audit trail to look more agile. We will not invent client names or savings percentages. We will not staff a project with a framework lecture and a junior who has never restored a backup. We will not call a prototype an MVP because the date was a festival.

How to brief this work

Write the job in one sentence. Name the sheet or the WhatsApp group it replaces. Name the systems that stay — Tally, attendance, the public site. Write who signs in and what they must not see. Attach one redacted example: a dispatch note, a claim, a dealer price row. Name who will sit with the build and who will own exceptions after go-live. List what is out until the first sentence is true.

If that page is honest, we can say “slice”, “discovery”, or “not yet”. If you want to start from that page, contact us with the sentence and the example. Bring the unofficial list, not a moodboard. The unofficial list is the product.