Bhopal has a real software industry now. It also has a lot of companies whose portfolio is stock imagery and whose "team of 50 engineers" is a WhatsApp group of freelancers. Both look identical on a website.
This is the checklist we would use if we were buying instead of selling. Some of these questions are uncomfortable for us too, which is rather the point.
Before the first meeting
1. Does their own website work?
Open their site on your phone, on mobile data, not office WiFi. Then look at three things: how long it takes to become usable, whether the contact form actually submits, and whether their phone number is the same in every place it appears.
A development company that ships a 20 MB homepage or a contact form that goes nowhere is telling you precisely how much care your project will get. We say this having found exactly those faults on our own site and fixed them — the point is that it is checkable in ninety seconds, and most buyers never check.
2. Can you find the same company details everywhere?
Search the company name and compare the address and phone across their site, Google Business Profile, LinkedIn and MCA records. Mismatches mean nobody is minding the details.
While you are there, note the CIN and look it up on the MCA portal. Incorporation date, registered address and directors are public. A company claiming "since 2013" with a 2023 incorporation is worth a follow-up question — there may be a perfectly good answer about a proprietorship converting to a private limited, but you want to hear it.
3. Are they anywhere buyers can leave reviews they cannot delete?
A testimonial on a company's own website is marketing copy. A review on Clutch, GoodFirms or Google is a review. The difference matters because one of them cannot be edited by the vendor.
If a company has no presence on any platform where clients speak independently, ask why. There may be a reason. There may not.
In the first meeting
4. "Who exactly will write my code?"
The answer you want names people and their roles. The answer that should worry you is a generic "our team of experts." Ask whether the people in this meeting will be on your project, or whether they are the sales layer and delivery goes to someone you have not met.
Follow up with: "Will you introduce me to the tech lead before I sign?" A confident firm says yes immediately.
5. "Show me something you built that went wrong."
This is the single most revealing question in the list.
Every company with real delivery history has a project that overran, a client relationship that soured, or an architecture decision they regret. A vendor who says nothing has ever gone wrong is either inexperienced or not being straight with you. What you are listening for is whether they can describe the failure specifically and what changed afterwards.
6. "What will you say no to?"
Good engineering firms decline things: features that will not work, timelines that are fantasy, technology choices that will hurt you in a year. A vendor who agrees to everything in the first meeting will agree to everything in month four as well, and that is how projects die.
7. "Walk me through what happens in week one."
Vague answers mean there is no process. You want to hear something concrete: who they interview, what they document, what artefact you receive at the end, and what decisions you will be asked to make.
Before you sign
8. "Is the scope written down in a form I could hand to another company?"
This is the practical test of a specification. If your requirements document is so vague that a different vendor could not build from it, then you have no way to verify delivery and no way to leave.
Insist that scope, timeline, cost and acceptance criteria are written before any code is written. Every serious firm does this as standard. Any resistance to it tells you something.
9. "Who owns the code, the repository and the credentials?"
You should own all three. This sounds obvious and is violated constantly.
Specifically: the source code repository should be in your organisation's account with the vendor invited, not the reverse. Cloud hosting, domain, database and third-party API accounts should be registered to your company email. Vendors who hold your credentials hold your business.
10. "What does support cost after launch, and what is the response time?"
Software is not finished at launch; that is when it starts being used. Get the post-launch arrangement in writing before signing the build: what is covered, what is billable, how fast a critical bug gets a response, and what happens at 11pm on a Sunday when payments stop working.
11. "What happens if we stop working together?"
Ask it plainly. A professional answer covers handover documentation, credential transfer, a transition period and the final invoice position. An evasive answer here predicts an ugly exit, and exits are when relationships actually get tested.
Three answers that should end the conversation
"We'll start coding right away." Without discovery, they are building what they assumed rather than what you need. You will pay to find out the difference.
"That will be ready in two weeks" — said in the first meeting, before seeing your systems. Either they have not understood the problem or they are buying the deal with a number they cannot hit.
"You don't need to worry about the technical details." You are going to own this system for years. Any vendor who wants you uninformed is optimising for their convenience, not your outcome.
What this looks like from our side
We lose deals over question 6 fairly regularly. A prospect wants a feature, we explain why it will not work at their volume and propose something different, and they buy from the company that said yes. Sometimes they come back a year later and sometimes they do not.
We would still rather answer question 5 honestly. The projects we regret are the ones where we agreed to a timeline we did not believe in, because nobody wanted to have the difficult conversation in week one.
FAQ
How do I verify a software company in Bhopal is legitimate?
Check the CIN on the MCA portal for incorporation date, registered address and directors. Confirm the same address and phone number appear consistently on their website, Google Business Profile and LinkedIn. Look for reviews on a platform the vendor cannot edit, such as Clutch, GoodFirms or Google. Then ask to be introduced to the technical lead who would actually work on your project before you sign anything.
What should a software development contract in India include?
At minimum: a scope specific enough that another company could build from it, a sprint-by-sprint timeline, fixed cost with a written change-request process, acceptance criteria per milestone, explicit assignment of intellectual property and source code to you, credential and repository ownership in your company's accounts, a post-launch support arrangement with response times, and exit terms covering handover documentation and transition.
Should I hire a local Bhopal company or a larger firm in Bangalore or Pune?
Local firms offer easier in-person access, lower cost, and usually more senior attention on a mid-sized project because you are a significant client rather than a small one. Larger metro firms offer deeper specialist benches and stronger process maturity, but a small project often lands with their most junior team. The deciding question is not the city — it is whether the people who impressed you in the meeting will be the people doing the work.
How much should custom software cost in Madhya Pradesh?
A straightforward business web application typically runs Rs 3,00,000 to Rs 12,00,000. Mobile applications with a backend usually start around Rs 5,00,000. ERP implementation and integration varies widely with the number of modules and legacy systems involved. Be suspicious of quotes far below these ranges: the shortfall usually reappears as change requests, or as software that cannot be maintained once the original developer leaves.
What are the warning signs of a bad software vendor?
Agreeing to every request without pushback, quoting a timeline before understanding your systems, refusing to introduce the technical team, holding repository or cloud credentials in their own accounts, having no written scope, no independent reviews anywhere, and being unable to describe a single project that went wrong.