Choosing a development partner is mostly done on impressions: the portfolio, the office, whether the meeting went well. Those tell you how a company presents itself, which correlates weakly with how a project goes when something is harder than expected.
The questions below are the ones we would ask in your position. They are uncomfortable in places, and a supplier worth working with will answer them without difficulty, because they have thought about all of it before.
"Who exactly will do the work?"
The people in the pitch are frequently not the people on the project. Ask for the actual team, their seniority, how much of their time you get, and whether any of them are still finishing something else.
Ask what happens if the lead developer leaves mid-project. A good answer describes code review, shared ownership and documentation — the practices that mean no individual is irreplaceable. A vague answer means you are buying one person's availability.
"How will I see progress?"
You want working software at a regular cadence, not status reports. Ask when you will first be able to click on something, and how often after that.
The answer "you will see it at the end" is the single strongest predictor of a project going badly. Long stretches without visible output are where misunderstandings compound quietly.
"What happens when we disagree about whether something is a bug?"
Every project reaches this. The useful answer refers to the specification and the agreed definition of done, not to goodwill.
Follow it with: what is included after launch, for how long, and what counts as a defect rather than a change? Getting this in writing before signing costs nothing; getting it agreed afterwards costs a relationship.
"Who owns the code, the accounts and the data?"
The answer should be: you do. Source code in a repository you own, infrastructure in accounts in your name, domains registered to your company, and third-party services subscribed by you rather than by them.
Suppliers who host everything in their own accounts are not necessarily acting badly, but the arrangement makes leaving them expensive, and that is worth knowing before rather than during.
"How do you handle security and personal data?"
Listen for specifics: how secrets are managed, whether production data is used in staging, who has access to what, how they respond to a vulnerability in a dependency.
For anything touching personal data, ask directly about GDPR — the lawful basis, deletion, retention, and the data processing agreement they will sign. A supplier who has never been asked this before is a supplier who has not built for a client who cared.
"What does the handover look like?"
Ask this even if you intend to keep working with them. The answer reveals how the work is being done.
You want to hear about documentation, a repeatable deployment, environment setup that works from a clean machine, and infrastructure described as code rather than assembled by hand. A team that can hand over cleanly has built something maintainable; a team that cannot has built something that only they can operate, whether or not that was the intention.
"Tell me about a project that went wrong."
The most informative question of the set. Everybody has one. What you are listening for is whether they can describe it specifically, what they concluded, and what they changed as a result.
An answer that blames the client entirely is a warning, because eventually you will be the client. An answer with no example at all means either a very short history or a reluctance to be candid, and neither helps you.
"What would you push back on in our brief?"
Ask it directly. A supplier who has read the brief carefully has an opinion — something over-specified, something missing, something that could be bought instead of built, a sequence that would reduce risk.
Enthusiastic agreement with everything is not a good sign. You are buying judgement as much as capacity, and judgement that never disagrees is not judgement.
Reading the answers
Across all of these, the pattern that predicts a good project is specificity. Suppliers who describe their process concretely, name trade-offs and admit limits tend to run projects the same way.
The opposite pattern — everything is possible, everything is easy, every timeline is achievable — is not confidence. It is the sound of decisions being deferred to a point at which they will be your problem.