How to choose a software developer: 12 questions to ask

In module APP.7 Development of Individual Software (external site) (in German), Germany’s Federal Office for Information Security (BSI) lists hiring unsuitable software developers as a threat in its own right. The consequences range from avoidable security vulnerabilities to considerable delays. According to the BSI, one reason for the wrong choice is cost calculations that are too tight and unrealistic.

If you’re planning a product you want to sell yourself, our guide to SaaS explains what’s involved. For the selection itself, have three things ready:

• Your requirements: the goal, the users and the workflows the software has to support. Our guide to writing a software requirements specification shows how to put them on paper.
• Your constraints: budget, target date, existing systems and what should happen after launch.
• Your criteria: Decide up front which questions count most for you. For software selection, the Chamber of Commerce and Industry of the Stuttgart region (external site) (IHK Region Stuttgart, in German) advises a structured process with clear criteria and no more than three to five options on the shortlist. In our assessment, the same makes sense for providers.

By “provider,” we mean individual developers as well as software companies.

Done when your requirements are in writing and every provider on your shortlist has received the same 12 questions.

Question 1: “Do you first check whether off-the-shelf software would do?”

According to the BSI, custom software is for tasks that can no longer be solved adequately with unmodified software. Our build-or-buy comparison shows when each option pays off.

Good answer: The provider names off-the-shelf products that could cover your workflow and explains why they would or wouldn’t be enough. It also advises against custom software if that wouldn’t pay off.

Red flag: Off-the-shelf products never come up in the conversation, and every problem supposedly needs custom software.

Done when you have in writing which off-the-shelf products were checked and why they aren’t enough for your workflow.

Question 2: “What can you show me from comparable projects?”

Providers rarely back up results with numbers on their websites. In our review of 17 providers, none shows a project result with a baseline and an end value on its main service page. What counts, then, is what a provider can show you in a conversation.

Good answer: The provider describes a project with similar workflows or interfaces, states its own role and says whether the software is still running. You’re allowed to talk to the client or see anonymized documents.

Red flag: Only logos and star ratings, and supposedly no one is allowed to talk about any project.

Done when you’ve talked to a past client or seen documents and know what the provider itself built on that project.

Question 3: “Who will work on my project, and who covers for that person?”

Researchers use the truck factor to describe how much a project depends on individuals. It’s the smallest number of developers who would have to drop out before a project stalls. In a study of 133 popular GitHub projects (external site), that number was two or fewer in 65% of the projects. Comparable figures are missing for client projects; in our assessment, the same risk exists there. In module APP.7, the BSI advises taking the qualifications of the assigned staff into account.

Good answer: You know the names or roles of the people involved, and you talk to the person who writes the code before you sign. The provider says who takes over during vacations or sick leave and how knowledge is shared.

Red flag: The team is decided only after you sign, or you only ever talk to sales.

Done when the quote names people or roles and you’ve talked to the person who will build your software.

Question 4: “How did you arrive at your price, and what isn’t included?”

Early estimates vary widely. At the start of a project, they can be off by a factor of four in either direction, according to software engineering author Steve McConnell, even when skilled estimators make them (Cone of Uncertainty (external site)). He recommends making firm commitments only once the scope is clear. Our cost guide How much does custom software development cost? lists market prices with sources. Our article on fixed price vs. time and materials compares when each model fits.

Good answer: For each module, the quote states the estimated person-days, the assumptions and what’s excluded, for example: “Order entry, 12 person-days. Assumption: master data is supplied as a cleaned CSV file. Not included: ERP integration.” If the scope isn’t settled yet, the provider gives a range with the open points or proposes an analysis, after which it names the fixed price.

Red flag: A binding fixed price after a short phone call, or a total with no breakdown.

Done when you have person-days, assumptions and exclusions in writing from every provider and can compare total costs over several years.

Question 5: “What happens when requirements change?”

Requirements are often not fully settled at the start of a project. According to the BSI, agile process models adapt better to this but don’t offer the same cost certainty as linear models. Either can work as long as the process for changes is defined.

Good answer: Changes go through a written change request that states the effect on price and schedule before work begins. The provider says who approves changes on your side and which process model it follows.

Red flag: “Changes are no problem,” but nobody says how they’re billed. A provider that rejects every change is just as difficult.

Done when the quote spells out how changes work, including who approves them and the effect on price and schedule.

Question 6: “How often will we see working software?”

According to the BSI, delays and wrong priorities can follow if the client doesn’t steer development adequately. Regular demos are one way to prevent that. In the Scrum Guide (external site), the team reviews each outcome with the stakeholders and discusses what comes next, and each interim result has to be usable.

Good answer: You see working software at fixed intervals, for example every week or every two weeks. You have access to the task list and to the repository, where the source code is stored.

Red flag: Status reports only, or the first demo comes just before the end.

Done when the demo schedule and your access to the task list and repository are in the quote.

Question 7: “How will we know when something is done?”

“Done” means whatever was set down in writing beforehand. The Scrum Guide calls this the Definition of Done: “a formal description of the state of the Increment when it meets the quality measures required for the product.” For sign-off, you need acceptance criteria with a defined expected result. The BSI advises involving process owners in testing even before final sign-off. Ask your legal counsel what legal effects sign-off has.

Good answer: There’s a written definition of “done,” such as code reviewed, tests passed, documented. Every important requirement has an acceptance criterion, and your own experts test early on.

Red flag: Sign-off is a meeting at the end of the project, and nobody can say what will be checked there.

Done when the acceptance criteria and the definition of “done” are in the draft contract and it’s settled who will test on your side.

Question 8: “Who reviews the code, and how is it tested?”

In module CON.8 Software Development (external site) (in German), the BSI requires testing during development, including with invalid input, and a check of the source code for errors. Under Google’s code review standard (external site), a reviewer has ownership of and responsibility for the code under review. Applied to your project, that means a second person reads every change before it goes into the shared repository.

Good answer: A second person reviews every change, and automated tests run on every change. A developer who works alone says who reviews their code and how they catch errors before those errors reach you.

Red flag: Testing happens only at the end and by hand, or there’s no second review.

Done when you’ve seen in an example how a change gets reviewed and tested, and the rules are in the quote.

Question 9: “What standard do you follow for secure development?”

Ask specifically about the security of the product the provider builds. In its guide for software buyers (external site), the US Cybersecurity and Infrastructure Security Agency (CISA) observes that many standards used in procurement focus on a company’s own security and relatively few on the product’s. As a basis you can verify, a provider might name one of these, for example:

• the Secure Software Development Framework (external site) from the US National Institute of Standards and Technology (NIST), which is also meant to give buyers a common vocabulary to use with suppliers,
• the OWASP Application Security Verification Standard (external site), which is explicitly also intended as a basis for requirements in contracts,
• the BSI’s Technical Guideline TR-03185 (external site) on the secure software lifecycle.

Good answer: The provider names a basis like this and shows how it’s put into practice. It delivers a software bill of materials (SBOM) and says how it handles reported vulnerabilities.

Red flag: “We’re GDPR-compliant” is the only answer, or nobody is responsible for security updates.

Done when the quote names the basis for secure development, the SBOM and how vulnerabilities are handled.

Question 10: “Do you use AI tools, and who reviews the output?”

AI tools are now part of everyday programming. In Stack Overflow’s 2026 Developer Survey (external site), 73% of respondents use coding assistants and agents daily. People still have to check the output: in tests that security vendor Veracode published in October 2026, AI-generated code contained a known vulnerability in about 38% of test tasks when the task gave no security-specific guidance.

Source: Veracode (external site), Oct 29, 2026 · vendor study · 18 models, four programming languages, four types of vulnerabilities

Whether AI shortens a project remains open. In a randomized trial by the nonprofit METR (external site), experienced open-source developers took 19% longer with AI in early 2025. METR now calls those results out of date, but it also considers its newer data (external site) an unreliable signal. Our article What is vibe coding? covers what studies show about the security and maintainability of AI-generated code. Our review of 10 providers’ standard terms shows how providers address AI use.

Good answer: The provider names the tools and says whether your code or data ends up in them. A person reviews every change an AI tool writes, just like any other code.

Red flag: Nothing said about AI use, or shorter timelines thanks to AI with no word on who reviews the code.

Done when you know which AI tools are used, whether your data ends up in them and who reviews the output.

Question 11: “Who maintains the software after launch, and what does it cost?”

Under the BSI’s module CON.8, security-critical updates must be provided promptly, even when third-party components are affected. Providers rarely publish prices for maintenance, support or operations: in our review, three of 17 did. Our cost guide How much does software maintenance cost? covers market prices.

Good answer: A maintenance quote states the scope, hours and price, for example for security updates and monitoring, and says how quickly the provider responds to incidents. Work outside the contract has a stated hourly rate.

Red flag: “We’ll talk about that after launch,” or the quote says nothing about maintenance.

Done when you know the ongoing costs over several years and who installs security updates.

Question 12: “What do I get if we part ways?”

For outsourced IT operations, the BSI’s module OPS.2.3 on outsourcing (external site) (in German) requires rules for both a planned and an unplanned end of the relationship. In our assessment, a development contract needs them, too. Our guide to avoiding developer lock-in explains what that takes in detail, such as accounts, rights and documentation.

Good answer: Code and accounts are in your company’s name from the start. The contract covers usage rights, source code, documentation and the end of the working relationship.

Red flag: The code arrives only at the end of the project, accounts are in the provider’s name, or the answer is “You don’t need that.”

Done when your draft contract covers every point on our contract checklist and an IT lawyer has reviewed it.

For software selection, the Stuttgart chamber of commerce recommends points per criterion and a total score for direct comparison. For the 12 questions, we suggest this simple scale:

• 0 points: no answer, or an evasive one.
• 1 point: The answer makes sense but isn’t backed up.
• 2 points: The answer is backed up with a document or an example.

In our assessment, a zero on question 3, 8, 9 or 12 should rule a provider out, even if its price is low. After that, proceed in stages: start with a small, paid assignment that has its own deliverable, such as an analysis or a clearly scoped pilot. That way, you see how the provider works before you commission the whole project.

Done when you have a scoresheet for every provider, the deal-breakers have been checked and the small first assignment is described.

• BSI checklist: APP.7 addresses clients and CON.8 addresses development. Ask which CON.8 requirements the provider meets, and plan for the APP.7 requirements on your side, such as having process owners test early.
• The chamber’s catalog of criteria: The Stuttgart chamber of commerce offers a catalog for selecting IT service providers, with sections on organization, prevention, response and the supplier. It’s aimed at IT security and fits question 9.
• Data protection and providers outside the EU: If the provider processes personal data, data protection belongs in the contract. Also agree on working hours and language, and find out where your data will be processed. Ask your legal counsel what this means legally.

Done when you know which BSI requirements the provider meets and where your data will be processed.