12 Questions to Ask Before Hiring a Software Development Company

A sales call with a development company is built to go well. Everyone is friendly and every answer is yes. The useful questions to ask a software development company are the ones whose answers can be checked: a name, a document, a login, a clause in the contract. Here are twelve, each with the reason it matters and what a good answer sounds like.

We are a development company ourselves, so these are also the things we expect to be asked. Put them to us as well.

People and ownership

1. Who will write the code, and can we speak to them?

Why it matters. The people who sell a project are often not the people who build it, and some companies pass work to subcontractors the client never meets.

A good answer names the developers, offers their resumes and an interview, and says plainly whether they are employees. Our own answer is that our developers do the work and nothing is subcontracted.

2. Who owns the code, and where does it live from the first day?

Why it matters. If the code sits only in the vendor's account, leaving the vendor means asking permission to take your own product.

A good answer: the contract assigns the source code to you, and the repository is in an organization account you own, with the vendor invited in. The same goes for hosting, domains and app store accounts. Have a lawyer read the ownership clause.

3. Have you built something like this, and can we see it?

Why it matters. Experience with your kind of problem is worth more than experience with a programming language.

A good answer shows working examples, explains what was hard about them and admits which parts of your project are new to the team. Ask for a reference you can phone yourself.

What to ask a software development company about scope and money

4. What is included in the quote, and what is not?

Why it matters. Two quotes for "the same project" can differ because one leaves out design, testing, content entry, deployment or fixes after launch.

A good answer is a written list of assumptions and exclusions next to the price, plus any third-party costs you will pay directly, such as hosting or licenses.

5. What happens when we change our minds?

Why it matters. You will. Every project learns something halfway that changes the plan.

A good answer describes a mechanism: a change request that is estimated and approved before work starts or, with dedicated developers, a backlog you can reorder at any time. "No problem, we are flexible" with no process behind it is how disputes begin.

6. How was this estimate made, and what if it turns out wrong?

Why it matters. An estimate is a forecast. You need to know who pays when it misses.

A good answer shows a breakdown by feature, names the uncertain parts and states who carries an overrun under the contract. An offer of a short paid discovery phase before a fixed quote is a sign of care, not of upselling.

How the work is run

7. How will we see progress?

Why it matters. Status reports describe activity. Only working software shows progress.

A good answer: a staging site you can open whenever you like, a demo every week or two, and access to the task board. Ask to see a sample progress update from another project with the client's details removed.

8. How is the work tested before we see it?

Why it matters. If the developer who wrote a feature is the only one who checks it, you become the tester.

A good answer mentions code review by a second developer, a QA person who is not the author, a list of devices and browsers, and automated tests on the parts that handle money or permissions.

9. How do you handle security and our data?

Why it matters. A vendor has access to your systems and your customers' data from the first week.

A good answer is concrete: who gets access and how it is removed, where credentials are stored, whether real customer data is used in development, and which checklist the team builds against. The OWASP Application Security Verification Standard is a common reference. Treat "we are fully compliant" with caution unless it comes with the name of the standard and of whoever verified it.

Launch and after

10. What happens after launch?

Why it matters. Software needs updates, fixes and small changes for as long as it runs, and the build team may be on another project a week later.

A good answer separates a period for fixing defects from an ongoing maintenance and support arrangement, and puts response times in writing. Our explainer on support SLAs shows what to look for in those terms.

11. What does handover look like if we part ways?

Why it matters. Asking at the start is easy. Asking during a dispute is not.

A good answer lists what you receive: the full repository, credentials, deployment instructions, documentation and a handover call, within a stated notice period. Compare it with our handover checklist.

12. What kind of project would you turn down?

Why it matters. A company that takes anything will take yours even when it does not fit.

A good answer names real limits: technologies the team does not work in, timelines it considers unrealistic, project sizes outside its range. Being told "this part is not our strength" during sales is the best evidence you will get of honesty later.

How to weigh the answers

Put the answers from each company in a simple grid and mark every one that came with evidence: a sample contract, a sample status update, a test plan, a name. Promises made only on a call score nothing. The pattern across twelve rows is usually clearer than the price comparison.

Then test the relationship cheaply. A small paid first step, such as a discovery phase or one milestone, shows you how the team communicates before the large commitment.

Keep in mind that a company is not always the answer. One contained task is freelancer work, and a product that is your whole business eventually deserves in-house engineers. A development company fits when you need several skills working together: as a quoted custom software development project when the scope is firm, or as a dedicated development team when it will keep changing. The projects in our portfolio are a fair place to start on number three.

Frequently asked questions

How many development companies should I talk to?

Three to five. Fewer and you have nothing to compare. More and you cannot give each a proper conversation, so the replies become generic. Shortlist on evidence of similar work before you ask anyone for a quote.

Should I choose the lowest quote?

Only after checking what it leaves out. Line up the assumptions and exclusions from each vendor and price the gaps. A low quote with testing, deployment and post-launch fixes excluded is often the most expensive option by the end.

Is it reasonable to ask for a paid trial or discovery phase?

Yes, and good companies welcome it. A short paid engagement produces something you keep, such as a scope, a prototype or a first feature, and shows how the team works. Be wary of large free "trials", which someone has to pay for eventually.

When should we sign an NDA?

Before you share anything you would not want a competitor to read: financial figures, customer data, unreleased plans. An established company signs one without difficulty. For a first conversation about a typical website or application, it is seldom needed.