How to choose a software house: 9 questions that show whether they will deliver

Software house proposals look alike: a portfolio, a list of technologies, a price. The difference shows in what the vendor puts in front of you before the contract. Below are nine questions to ask on the first call. The answers tell you more than a company presentation.

Before you start asking

Price alone does not let you compare offers. Two quotes for the same idea often describe two different products: one includes testing, security and maintenance, the other does not. Compare the way of working, not only the amount. We describe how to prepare a brief for a quote in How much does an app cost.

Ask every candidate the same questions and write down the answers. Look for specifics: tool names, dates, documents you can see. "Of course, that's standard for us" tells you nothing.

A simple scoring helps the decision. For each answer give 0 points when specifics are missing, 1 point when the vendor describes a practice and 2 points when they show proof: a document, a tool, a contact. You can compare the totals between companies faster than notes from several calls. Treat questions 2 and 4 as hard requirements, whatever the score.

Invite a technical person from your side to the call if you have one. If you do not, ask the vendor to explain the answers in business language. Explaining well is part of the service.

Nine questions and the process stage where the vendor has to answer them with actions.

Questions 1 to 3: everyday work

1. Will I get a test environment and a demo every sprint? A good vendor works in short cycles and shows a working product, not slides. With us that means two-week sprints, a demo after each one and a staging environment you can open at any time. Ask when you will see the first working version. If the answer is "at the end", the risk grows every week.

2. Who owns the code and the accounts? The code, designs, repository, cloud accounts and app store accounts should be yours from day one. Ask whose name the domains and the Apple and Google developer accounts are registered under. A vendor who holds the keys holds you too.

3. How do you check code quality? Ask for a description of the process: code review by a second person, automated tests, CI setup. Ask what happens when a test fails and who can approve a release despite a red result. With us the vendor owns quality: automated tests, code review and security are part of every sprint, and you set the priorities. A good answer names steps and tools, while a weak one stops at adjectives.

Questions 4 to 6: risk before launch

4. Do you run a security audit before launch? This question separates vendors who treat security as part of the process from those who treat it as an add-on on request. With us the audit is part of the Launch stage. It starts with written consent for testing and ends with a report and a retest. We described the details in Application security audit: 12 things we check before launch. Ask whether the vendor will show a sample report without client data, and whether a critical finding blocks the launch.

5. Will I get a fixed quote and a written scope? A fixed quote comes after discovery, not from a single email. Ask what exactly is in the scope and how the vendor handles changes that appear along the way. A good answer describes who raises a change, who prices it and when you approve it. Hourly billing with no cap can be fair, but then ask for a budget ceiling that triggers your decision about next steps.

6. Who will be on the team, and will it be the same people to the end? Ask for names and roles: who leads the project, who designs, who writes code. Check that you are talking to people who will work on your product. A salesperson who disappears from the project after signing is a weak starting point. A good sign is a stable team and one contact channel.

Questions 7 to 9: after the contract and before it

7. What happens after launch? An application without care ages: libraries get security patches, mobile systems change their requirements, certificates expire. Ask about monitoring, updates, vulnerability patching and how often you receive a report. With us the report arrives every month, and you adjust the scope of care month by month.

8. What does onboarding look like? A good start is a discovery workshop with key people from your company. A map of processes, risks and priorities goes into one document that both sides approve. If a vendor quotes without such a workshop, the quote is a guess. With us onboarding takes 1 to 2 weeks, and its result is a scope, a schedule and a fixed quote.

9. Can I see references and code from previous projects? Ask for a contact at a client who agrees to talk, and for a sample of code or documentation the vendor can show without breaching confidentiality. If code cannot leave the client, ask for an architecture description or a walkthrough on a shared call. A vendor with nothing to show usually has no process either.

Red flags and good signs

After the call, compare the answers with this table. One red flag is a reason to ask more. Three are a reason to talk to someone else.

The five most important contrasts. The full list of nine questions is in the table below.

How the questions map to the process

The nine questions cover all six stages of working together. You judge a vendor over the whole cycle, so the questions reach from the first call to maintenance.

• Idea: the first call and question 9. Will the vendor tell you a smaller scope is enough?
• Onboarding: questions 5, 6 and 8. Scope, schedule, fixed quote and a stable team.
• Design: a clickable prototype in Figma before any code exists. A change at this stage costs hours, not weeks.
• Product: questions 1, 2 and 3. Demo, staging, code review and tests.
• Launch: question 4. Security audit, acceptance tests, production and app stores.
• Growth and care: question 7. Monitoring, vulnerability patching, a monthly report.

After every stage you decide whether you continue. Ask each candidate whether the contract gives you that option.

What to do today

Pick two or three companies you are considering and send them questions 2, 4 and 7. The answers to these three show who thinks about your product after launch and who thinks only about delivering it. Write down how many hours it took to get a reply. It is a good sample of the collaboration.

If you already have an application built by someone else and you are changing vendors, start with Taking over an existing app.

Tell us about your idea

We are happy to answer these nine questions about your project. The first call takes about an hour and is free. You get a note with a recommendation and a first estimate, and you decide whether we go on. Tell us about your idea.