Buying and running software in India
Indian buyers usually arrive with a working business and a spreadsheet that has stopped coping, not with a greenfield brief. The common starting point is a WhatsApp-driven operation — orders, service requests, staff coordination and customer follow-up all living in chat threads — where the goal is to move that into software without asking staff to abandon WhatsApp entirely. That constraint shapes the build more than any technology choice does.
UPI has changed what a checkout has to look like. A payment flow that only handles cards reads as broken to an Indian customer, so Razorpay, PayU or PhonePe integration with UPI intent and QR handling is usually in scope from the first milestone rather than added later. GST adds its own requirements: invoice series, HSN/SAC codes on line items, and reporting that an accountant can reconcile. These are specified against the operator's own filing setup, not assumed.
Hosting is frequently a VPS the business already rents, often with CloudPanel or cPanel in front of it, and the expectation is that the source code is handed over and runs there. Deployment on Nginx, PM2 or Docker on client-owned infrastructure is the normal case rather than the exception.
Teams are typically small and non-technical, so admin screens are built to be operated by someone who was trained for twenty minutes, not someone reading documentation.
API & Payment Integration in India
Payment work in India centres on UPI rather than cards. Razorpay, PayU and PhonePe each expose UPI intent, collect requests and dynamic QR differently, and the choice usually follows whichever gateway the business already holds a merchant account with. Webhook handling for delayed UPI confirmations matters more than it does on card-only flows, since a customer may complete payment after leaving the page. Settlement reporting is mapped to the operator's existing accounting process.