Red flags when hiring a software company in India

Most failed software projects do not fail in the code. They fail in the first two weeks, when the brief is fuzzy, ownership is unclear, and nobody agrees what “done” means. This guide lists the warning signs we see when a business is about to buy the wrong engagement — and the written answers you should get before money moves.

It is written from delivery work at JantaraX, not from a marketing template. Use it on any vendor, including us.

• The proposal lists technologies but never names the user or the first outcome. If React and AWS appear before “store owner sees stock below reorder,” the plan is still marketing.
• There is no written list of what is out of the first release. Unlimited scope is how budgets disappear.
• Credentials, domain, hosting, and source access stay only with the vendor. If you cannot renew the domain without them, you do not own the product.
• Milestones are vague (“design,” “development,” “go live”) with no demo you can reject. You need checkpoints with something you can open and try.
• The quote assumes a fixed price for an undefined workflow. Fixed price needs a fixed boundary. Without one, either quality or trust will break.
• Nobody asks how your team works today. A vendor that skips the current spreadsheet, WhatsApp habit, or paper form will rebuild a fantasy process.
• After-launch support is “optional” with no named checks. Launch day is the start of maintenance, not the end of the project.

• Who uses the first version, and what job it replaces.
• The one outcome the first release must produce.
• What is explicitly out of version one.
• Who owns the domain, hosting, source, and admin accounts.
• Demo dates where you can accept or send back a slice of work.
• How support works in the first 30–90 days after launch.

If a vendor cannot put those six lines on one page, do not start. The project brief tool on this site helps you draft the first four. Bring that draft to the call.

A coaching institute wants “an app.” Two proposals arrive. Proposal A: Flutter, Firebase, admin panel, push notifications, ₹X for three months. Proposal B: first release is a signed-in staff tool to log enquiries, mark demo booked, and show unpaid follow-ups; student app and payments are out of version one; domain and GitHub under the institute; demos every two weeks.

Proposal B is longer to read and easier to manage. Proposal A sounds modern and leaves every hard decision for later. Choose the one you can check against your Tuesday morning work.