o checklist can predict whether a supplier will close, become unavailable or simply stop responding. It can reveal whether your project is designed to survive that event. The safest relationship combines trust with practical continuity: the business owns critical accounts, progress is inspectable, payments follow evidence and another competent team could take over.
A small studio is not automatically risky and a large agency is not automatically safe. Continuity comes from operating discipline, legal identity, transparent delivery and recoverable assets—not headcount or an impressive office.
- The proposal and invoice name the same legal person or company, with a usable address and registration details where applicable.
- The bank account, contract and supplier identity make sense together; unexplained last-minute changes are resolved before payment.
- The scope identifies the deliverables, exclusions, payment events, intellectual-property position, cancellation rights and handover.
- Named people own product decisions, engineering, approvals and communication.
- Claims about previous work can be checked with live examples or references, while respecting client confidentiality.
For a UK limited company, Companies House is a useful primary record for status, officers and filings, but incorporation alone is not a quality guarantee. Use it as one evidence point alongside references, the contract and how the team actually works.
- Pressure to pay the entire project immediately without a clear commercial reason.
- A price that cannot be reconciled with the promised team, duration and deliverables.
- Refusal to put scope, ownership or acceptance terms in writing.
- A domain, hosting account or app-store account that must be registered permanently in the supplier's name.
- No visible development cadence, demonstration rhythm or route for raising concerns.
- Testimonials that cannot be connected to identifiable work, or a portfolio made entirely of mock-ups.
- Evasive answers about who will maintain the product after launch.
A missed message is not evidence of disappearance. Look for patterns: repeated promises without artefacts, milestones declared complete without reviewable output, unexplained staff changes, increasingly urgent payment requests, access being withheld and long periods where nobody can demonstrate the current state.
- Meetings replace demonstrations instead of supporting them.
- The supplier cannot show the product in a shared environment or explain what changed.
- Invoices arrive ahead of the agreed acceptance event.
- Bugs and missing scope are continually reframed as a future maintenance problem.
- The business cannot access its repository, hosting, domain, analytics or design source.
- There is no release, backup or handover plan as launch approaches.
The client organisation should normally own the domain, DNS, hosting project, source repository, analytics, email service, payment account and Apple or Google developer accounts. Give the supplier role-based access. Ownership should not prevent the agency doing its work; it prevents the business becoming a guest in its own product.
- Create business-owned accounts before development starts.
- Invite named supplier users instead of sharing one master password.
- Require commits and design source to appear throughout delivery, not only at the end.
- Tie milestones to inspectable outcomes and written acceptance criteria.
- Keep decisions, dependencies, credentials ownership and open risks documented.
- Plan an offboarding rehearsal: list exactly what a replacement needs on day one.
A fair deposit reserves capacity and funds discovery. Later payments should correspond to meaningful delivery states: an approved direction, a working core flow, a launch candidate and production handover. Milestones should not encourage unfinished code to be called complete, so define acceptance and a reasonable correction window.
- Preserve emails, contracts, invoices, meeting notes and screenshots; do not make public accusations while facts are unclear.
- Check business-owned accounts and revoke access only if necessary to protect data or prevent unauthorised changes.
- Export repositories, designs, databases and configuration that you are entitled and able to access.
- Send a concise written notice that identifies missing obligations, a response deadline and the requested handover.
- Seek qualified legal advice for the contract, recovery options and data responsibilities.
- Ask a replacement technical team for a read-only recovery assessment before changing production systems.
Do not attempt to seize supplier accounts, bypass access controls or copy assets you do not own. The aim is a lawful, documented recovery. If personal data or security may be exposed, treat that as an incident rather than merely a commercial disagreement.
Thebestprotectionisnotsuspicion.Itisadeliverysystemwheretrustissupportedbyclientownership,visibleworkandatestedexitroute.