Hiring a software company is a bigger decision than hiring most suppliers. You are not buying a finished thing; you are buying months of judgement, communication, and craft from people you have just met. The proposal will look polished. The portfolio will look impressive. The questions below help you see what is behind them.
Ask them in the first or second conversation. The answers matter, but so does how they are answered.
Process
1. What happens before you write any code? Look for a discovery phase: interviews with the people who will use the system, a written scope, a prioritized release plan, and an architecture recommendation. A company that goes straight from your brief to a quote is guessing—and the guess becomes your problem later.
2. How will we see progress? Good answer: working software every two to three weeks, in an environment you can click through, with a short written update. Bad answer: a demo at the end.
3. What happens when requirements change? They will. You want a partner who expects change and has a way to handle it—re-prioritizing the backlog, estimating the impact, agreeing in writing—rather than one who treats every change as a dispute.
People
4. Who exactly will work on our project? Ask to meet the engineers and designer, not just the sales lead. Ask how many other projects they are running at the same time.
5. What happens if someone leaves mid-project? Documentation, code review, and shared standards are the honest answer. "It won't happen" is not.
Ownership and independence
6. Who owns the code, designs, and accounts? Insist that hosting, domains, app store accounts, and repositories are in your name, or transferred to you at handover. You should be able to walk away with everything.
7. Can another team maintain this later? Ask what documentation and handover you will receive. Ask whether the technology choices are mainstream enough that other developers can pick them up.
Quality
8. How do you test? Automated tests for critical paths, manual testing across real devices, and a defined review before each release. If the answer is "the client tests it", budget for bugs.
9. How do you handle security and data? Access control, secrets management, backups, and a plan for recovering from mistakes. For anything handling money or personal records, this is not optional.
After launch
10. What does support look like after launch? Monitoring, response times for fixes, and a way to request improvements. Software is not finished when it launches; it is finished when it is retired.
11. What will this cost to run each year? Hosting, third-party services, maintenance, and updates. A partner who cannot estimate running costs has not thought about your system as something that lives.
Fit
12. Have you told a client not to build something? The best answer includes a story. A company that has never talked a client out of a project is optimizing for revenue, not for you.
What a good answer sounds like
You are not looking for perfection. You are looking for people who are specific, who volunteer the risks, and who describe how they work rather than how great the result will be. A company that says "here is what usually goes wrong and here is how we handle it" will be easier to work with than one that promises nothing will.
Frequently asked questions
Should we choose a local company or work remotely? Both can work. What matters is communication rhythm, time-zone overlap, and whether you can meet the actual team. A Kathmandu company working with a client in Europe, for example, overlaps well in the client's morning.
How many companies should we talk to? Two or three. Enough to compare approaches, few enough that you can have real conversations with each.
Is the cheapest quote a mistake? Not automatically—but ask what it excludes. Discovery, testing, documentation, and support are the usual casualties.
These are the questions we would want to be asked. If you would like to put them to us, start a conversation—we will answer the awkward ones first.