How to use this question list
This is a script for the meeting where you sit down with the people who would build your software: the project manager, lead developer or analyst. It contains 24 questions grouped by the stage of the project they relate to, each with a description of what a good answer sounds like. Use it after you have confirmed the company is genuine and registered, which is covered in our guide on what to check before hiring a software company.
Take a colleague to write down the answers. Ask every company the same questions in the same order, so you can compare them afterwards. You do not need to understand the technical detail of every reply. Listen for whether the answer is specific to your project, whether it names a person or a step, and whether it admits limits. Vague confidence is a weaker answer than a clear "that depends, and here is what it depends on".
Discovery: how they will understand your work
| Question | A good answer sounds like |
|---|---|
| 1. How will you learn our process before quoting? | They describe meeting the people who do the work, looking at real forms and registers, and writing back what they understood. |
| 2. Who on your side will we deal with during requirements? | A named role, such as an analyst or project lead, who stays with the project. |
| 3. What do you need from us, and how much of our time? | A realistic estimate of meetings and reviews, and who on your side should attend. |
| 4. Which part of our requirement do you think is the riskiest? | They point to a specific step, integration or data problem and explain why. |
Question 4 is the most revealing. A team that has listened will have noticed something difficult. A team that says nothing is difficult has either not listened or is telling you what you want to hear. If you have already written a scope using our step-by-step scoping method, hand it over before the meeting so their answers can be specific.
Design: how you will see it before it is built
| Question | A good answer sounds like |
|---|---|
| 5. Will we see screen designs before development starts? | Yes, as layouts or a clickable mock-up, which you approve before coding. |
| 6. How do you design for staff who are not comfortable with computers? | Simple screens, fewer fields per page, local-language labels where needed, and trying the screens with actual users. |
| 7. Will it work on mobile phones as well as desktops? | A clear answer about which screens work on phones and whether a separate app is needed. |
| 8. How many rounds of design changes are included? | A stated number or a clear method, rather than "unlimited". |
If your staff include a counter clerk or ward attendant who rarely uses a computer, ask the team to show a screen they designed for a similar user. The answer to question 6 matters more than how attractive the dashboard looks.
Build: how the work will progress
| Question | A good answer sounds like |
|---|---|
| 9. How will we see progress during development? | Regular demos of working modules, not just status reports. |
| 10. Which technologies will you use, and why for this project? | A reason linked to your needs, such as hosting, future maintenance or availability of developers, not just the newest name. |
| 11. Who will write the code, and might that change? | Named roles, and an honest answer about what happens if someone leaves. |
| 12. How do you handle a change we ask for midway? | A written change request showing the effect on cost and dates, approved before work starts. |
On question 10, you are not judging the technology. You are checking whether the team can explain its choice in terms of your situation. A good answer might mention that the framework is widely used, so another developer could maintain the system later if needed.
Testing: how they will prove it works
| Question | A good answer sounds like |
|---|---|
| 13. How do you test before giving us a version? | A description of their own testing, including security checks and different devices or browsers. |
| 14. Will we test with our own real examples? | Yes, against agreed acceptance criteria, before sign-off. |
| 15. What happens to bugs found after we sign off? | They are fixed under a defined support period, with a clear way to report them. |
| 16. How will you check that our old data imported correctly? | Totals and counts compared between old and new records, plus sample checks with your staff. |
Question 16 is often forgotten. If opening balances, stock quantities or fee dues are wrong on the first day, staff lose trust in the new system immediately and go back to their registers.
Go-live and training: how the switch will happen
| Question | A good answer sounds like |
|---|---|
| 17. What does launch day look like? | A plan with a date, who is present, and what happens if something goes wrong. |
| 18. Should we run the old method alongside the new one for a while? | A view on whether a short parallel run suits your work, and for how long. |
| 19. How will each role be trained? | Separate sessions for each role, with simple written or video guides to keep. |
| 20. Who do our staff contact in the first week? | A named person or a dedicated channel, with hours stated. |
Listen for whether the plan fits your calendar. A school will not want to switch fee software in the first week of a new session, and a shop will not want to change billing just before a festival rush. A team that asks about your busy periods is thinking about your staff, not just its own schedule.
Support and the long term
| Question | A good answer sounds like |
|---|---|
| 21. What exactly does your AMC cover? | A written list covering bug fixes, minor changes, backups and updates, and what is charged extra. |
| 22. How do we report problems, and how are they prioritised? | A channel, working hours, and how urgent issues are handled differently from small ones. |
| 23. What will you hand over if we stop working together? | Source code or licence terms, the database, documentation and account access, as written in the contract. |
| 24. What would you need from us to keep this system healthy in three years? | Practical points such as renewing hosting, keeping user accounts current and planning upgrades. |
The last question shows whether the team thinks beyond launch. Software that is not looked after slows down, falls behind rule changes and loses users. A team that has supported systems for years will have a ready answer.
Scoring the answers and making the choice
After each meeting, score every answer from 0 to 2: 0 for vague or evasive, 1 for reasonable but general, 2 for specific to your project. Total the scores by stage as well as overall. A team that scores well on build but poorly on support may deliver on time and then be hard to reach. Discuss the scores with whoever will run the software daily, not just the person approving the budget.
If two teams score closely, ask each for a short, paid piece of work, such as a written requirement summary, before committing to the full project. How each one handles that small task tells you a good deal about how it will handle the larger one.
Answers you can expect from MATROP
If you put these questions to MATROP PRIVATE LIMITED, you will hear about our process for custom software development: requirement analysis of your workflow and pain points, UI/UX design of the screens your staff will use, development with module-wise demos, testing that includes performance and security checks, deployment with backup and monitoring, and then training, maintenance and feature upgrades. The technologies we commonly deliver include PHP with CodeIgniter or Laravel, Node.js, React or Angular, Android and iOS apps, and REST APIs.
We will also tell you when a ready product, such as our retail and distribution software, makes many of these questions simpler because the screens already exist. If you would like to go through this script with us, bring it to our Ranchi office or arrange a conversation.
Questions people ask
Should we meet the developers who will actually build our software?
Yes, if possible. The salesperson explains the offer; the developer or analyst shows whether your process has been understood, so ask for at least one of them at the second meeting.
How many companies should we interview?
Two or three is usually enough to compare answers properly. More than that makes it hard to remember who said what, unless you score every meeting the same way.
What if a team cannot answer a question in the first meeting?
That can be fine for detailed questions, as long as they note it and reply in writing soon after. Repeated vagueness on basic questions about process or support is a different matter.
Do these questions apply to a company selling a ready product?
Most of them do. Design and build questions matter less because the screens already exist, so spend more time on data import, training and support.
