Who will actually write the code, and will I speak to them? Work sold by one team and delivered by another loses context at the handover, and you will feel it as rework. Ask whether the person scoping the project is the person building it.
What do I own at the end? Source code, deployment configuration, documentation, and the cloud accounts. Get the answer in writing. A supplier who hesitates here is telling you something important.
What happens when requirements change? The answer should describe a documented amendment process with visible cost, not a reassurance that they are flexible. Flexibility without a process is how projects lose their scope quietly.
How will I know it works? Ask what testing looks like and whether requirements are traceable to checks. 'We test thoroughly' is not an answer; a specification with matching verification is.
What is out of scope? Data migration, training, third-party costs, and hosting are the usual gaps. Ask about each specifically rather than in general.
What happens if I stop working with you? A good supplier can describe the handover — documentation, credentials, and a runbook — without discomfort, because they have written it as they went rather than as an exit task.
And the two most suppliers hope you skip: can you show me something you built that went badly, and what did you change afterwards? Every firm has one. A company that claims otherwise is either very new or not being straight with you, and being new is the more forgivable of the two.