Most founders who outsource development are not equipped to evaluate what they are receiving. That is not a failure on their part — the work is genuinely opaque from outside. But the gap creates a specific failure mode: problems stay invisible until they surface as missed deadlines, and by then the cost of correcting course is high. Everything below can be checked without being able to read the code.
Check estimates before work starts, not after
The cheapest intervention is reviewing tickets before implementation. A ticket that does not state what done looks like will be delivered to whatever definition is most convenient. A multi-week estimate on a task nobody can describe in two sentences is a signal that the requirement is not understood yet. Ask for the ticket to be split until each piece is describable.
Ask for demonstrations, not status
Percentage-complete reporting is nearly information-free. Working software on a staging environment is not. Insist that progress is shown against the actual acceptance criteria, on an environment you can reach yourself. If a feature can only be demonstrated on a developer's machine, treat it as not delivered.
Verify you own what you paid for
- The source repository is under an account your company controls, and you are the owner rather than a collaborator.
- Infrastructure, domains, and third-party service accounts are registered to the company, not to individual developers.
- There is a written record of how to build, deploy, and roll back the application.
- Credentials and secrets are held somewhere that survives the vendor relationship ending.
This list sounds obvious and is very frequently wrong in practice. It is also the cheapest thing to fix early and the most expensive to fix during a dispute.
Watch for recurring patterns, not individual defects
Every project has bugs. What matters is whether the same category of bug keeps returning. Repeated regressions in the same area usually indicate missing automated tests. Repeated scope disagreements usually indicate that requirements are being written after implementation starts. Treat the pattern as the defect and fix the process, rather than escalating each instance.
Bring in an independent reviewer
A vendor reviewing its own work has an unavoidable conflict of interest, however honest the people involved are. A few hours a month from someone technical whose only obligation is to you changes the dynamic considerably — not adversarially, but because problems get raised while they are still cheap. That is the core of the technical oversight work I do.