Most software projects that go wrong do not fail in the code. They fail in the first few weeks, when scope is vague, ownership is unclear, and nobody agreed how decisions get made.
Ask how they scope the work
A good partner pushes back on a vague brief. They ask what success looks like, who will use the product, and what must be true on launch day. Be careful with anyone who quotes a fixed price before asking those questions.
Confirm who owns what
Ask what the contract says about who owns the code, the cloud accounts, the domain and the data, and get the answer in writing before you sign. Check that the terms match how the work is paid for, and that you can see who has access to your systems at every stage.
Look at how they communicate
Ask for a regular rhythm: a short written update each week, a shared tracker, and one named person who answers for delivery. Time zone overlap helps, but a clear cadence matters more than hours spent in the same room.
Plan the handover before you start
Ask what documentation, tests and runbooks will exist when the project ends. If the answer is “we will write that at the end”, the handover will be rushed and the team that inherits the system will pay for it.
- #SoftwareDevelopment
- #CustomSoftware
- #VendorManagement
- #ProductEngineering
Share this post