Vishvajeet Shukla
Loading page content…Half of this page is reasons not to hire me for one. That is deliberate — the wrong tool costs you twice, once building it and again replacing it.
Deliberately unexciting choices. Anything you build gets maintained for years, usually by someone who is not me, and that is worth more than a fashionable dependency.
TypeScript catches a whole class of mistake before it reaches your staff, and it is what makes the codebase readable for whoever maintains it after me. Not optional on anything that will be used daily.
A custom API when the data model is yours and complex; Firebase when speed of delivery matters more and the requirements are standard. I pick based on your case rather than on what I feel like writing.
PostgreSQL when the data is relational and reporting matters, MongoDB when documents and flexible shapes fit better. This gets decided in the first week, because changing it later is expensive.
A consistent interface built from reusable pieces rather than one-off screens. It keeps later additions cheap, which is where most of a system's lifetime cost actually lives.
Applications fail on adoption far more often than on code. These four steps exist to protect against that specifically.
Registers, spreadsheets, the WhatsApp group, whatever is actually in use. The system has to fit that sequence, because one that forces an unfamiliar order gets routed around within a month.
Stock, or orders, or job cards — not all three. Systems that try to cover every department at once take a year and get abandoned. Shipping one thing people genuinely use beats launching five they avoid.
Not just a development laptop. Entry-level Android phones, poor light, one hand free. This is what decides whether a floor team adopts the system or quietly keeps the register.
The old register and the new screen, side by side, until the data agrees. It feels like duplicate work and it is the cheapest insurance there is against discovering a gap after the register is gone.
Most businesses need a website, and I will say so rather than sell an application. React earns its place when a screen has to react to the person using it — an inventory grid that filters instantly, an order board that updates as staff work through it. If your requirement is pages people read, React adds cost and removes nothing.
React is the library that draws interactive interfaces. Next.js is a framework on top of React that adds server rendering, routing and image handling — the things a public website needs in order to rank. For a marketing site you want Next.js. For an internal dashboard behind a login, plain React is simpler and cheaper.
Buy, if a packaged product covers roughly eighty percent of what you need at a sensible licence cost — and I will tell you when that is the case. Building makes sense when your process is genuinely unusual, when per-user licences scale badly with your headcount, or when you need it connected to systems the packaged product will not talk to.
You own it outright. The repository goes to your account, the setup is documented, and it is written with standard tools any React developer knows — no unusual frameworks, no undocumented shortcuts. You should be able to hand it to another developer without them needing to speak to me first.
Usually yes, and the method depends on what you run. Tally exposes an XML interface that can be read and written to, most modern ERPs have an API, and where neither exists we fall back to a scheduled import and export. What matters is agreeing early which system holds the master copy of the data.
It needs designing for that specifically. Data already loaded stays visible, forms hold what was typed rather than clearing, and submissions queue and retry when the connection returns. Full offline operation is a larger build, so it is worth being honest about how often the connection actually fails before paying for it.
A focused one covering a single workflow is typically six to ten weeks including testing with your actual staff. Systems that try to cover every department at once take considerably longer and usually fail. Shipping one workflow that people genuinely use beats launching five that they route around.
Far less than most people assume. A dashboard for a small team typically runs on hosting and a database costing a few thousand rupees a month, sometimes less, and there are no per-user licences because you own the software. The real ongoing cost is occasional development when you want changes, on your schedule.
Tell me what your team does every day and where it goes wrong. If a dashboard is not the answer, I will say so before either of us spends anything.
