APIs: contract, ownership and exit

01 — Contract

What needs to be clarified in writing

• Ownership of data and access. They belong to the client. If a provider won't clearly confirm this, that's the most important information from the conversation.
• Handover upon termination. In what format, within what timeframe, at what cost.
• No minimum term without consideration. Lock-in is justifiable if something is delivered in return — otherwise not.
• What a later change costs. The total cost isn't determined by the project price, but by the hourly rate in year three.
• Documentation as a deliverable. Not as a promise, but as a line item in the proposal.

02 — Questions

Questions you should ask

• What happens if the project becomes more expensive than estimated — who bears that?
• Who owns data, access, and, if developed, the source code?
• What does operation cost in the second and third year?
• What does the documentation we receive at the end look like?
• How would you measure whether the project was successful?
• Is there a case in which you would advise us against this?

03 — Warning signs

When to be skeptical

• Guaranteed results. Anyone promising top Google ranking or a specific revenue increase is selling something they can't deliver.
• No pushback. A provider who thinks every project is a good idea has either not listened or is only selling.
• Time pressure. Limited-time discounts on project prices are a sales tool, not an offer.
• Unclear ownership. Anyone who won't clearly say who owns data and access doesn't have your interests at heart.
• No contact with technical expertise. If only sales sits in the first meeting, that's where misunderstandings arise.