Before the first sprint, ask for proof—not promises.
A proposal can describe a convincing result while leaving the working agreement unclear. Before signing, establish who controls the code and accounts, what the first release must do, how changes reach production, and what happens when the project needs support.
You do not need certainty about every technical decision. You need enough evidence to understand the unresolved decisions and who will own them. Use this checklist to turn a vendor conversation into a reviewable agreement.
Evidence to request before signing
| Area | Evidence to request | What needs clarification |
|---|---|---|
| Repository and account ownership | Written ownership terms; repository owner and access roles; owners of hosting, domains and required accounts; any transfer procedure. | Critical assets sit in personal accounts, or your access depends on one person. |
| Scope and acceptance | First-release scope, exclusions, assumptions, milestones and an acceptance check for each deliverable. | “Complete” has no observable definition, or dependencies remain unstated. |
| Deployment, secrets and rollback | Release checklist, access responsibilities, credential-handling approach and rollback procedure. Request a walkthrough using a safe example. | Nobody can explain who releases, who can recover the service or how credentials are protected. |
| Testing and security | Representative test plan, review process, dependency checks and security-defect tracking. Request sanitised examples rather than customer code. | Quality is described only as “we test everything,” without evidence tied to your main user journey. |
| Communication and escalation | Named decision owner, progress-report example, decision log and escalation route. | Meetings exist, but decisions and unresolved risks have no owner. |
| Handover and support | Documentation outline, access-transfer checklist, support boundaries and agreed response expectations. | Post-launch responsibility is left for a later conversation. |
A missing document is a question to resolve. A repeated refusal to clarify ownership, acceptance or recovery is a stronger reason to pause. The checklist helps expose delivery risk while you can still change the agreement.
Turn one feature into an acceptance check
Consider an illustrative customer portal project. “Build order tracking” is too broad to review. A more useful acceptance check is:
Acceptance check: An authenticated customer can see only their own orders and each order’s current status. An empty account shows a clear empty state. A failed request offers a retry. Access checks run on the server, and another customer’s order cannot be retrieved by changing its identifier.
This is an illustrative specification, not a completed CodeAustral engagement. It shows how a broad feature becomes behaviours that a buyer and delivery team can inspect together.
Ask the prospective partner to do the same for your first important user journey. Record the required behaviour, dependencies, exclusions and evidence that will establish acceptance. If the answer reveals uncertainty, make that uncertainty part of the scope discussion.
Check ownership and security separately
Repository ownership is one part of handover. Hosting, domains, credentials, deployment access and operating documentation also need explicit owners. GitHub’s repository-transfer guidance explains transfer mechanics; transferring a repository does not settle ownership of the surrounding service.
NIST’s Secure Software Development Framework provides a common vocabulary for discussing secure development with suppliers. Use it to ask concrete questions about practices and evidence. Referencing the framework does not demonstrate that a vendor follows it.
Name the team and the change process
Ask who will actually make product and technical decisions, review the code and lead delivery. Record whether those people are dedicated or shared, and how responsibility transfers if a key person leaves. A staffing model can include part-time specialists; it still needs named accountability.
Agree how new requests are evaluated before the first sprint. Define what counts as a scope change, who approves it, how dependencies affect the estimate and how budget risks are surfaced. A fixed price does not resolve an unstated assumption. Written change control makes it possible to choose a smaller release or investigate a dependency without silently changing the agreement.
Compare the surrounding decisions
For a broader partner-selection process, read How to Choose a Software Development Company. For a Next.js engagement, use the Next.js developer hiring guide to inspect framework-specific delivery evidence. This checklist focuses on the agreement before work starts.
Make the next conversation specific
Bring the first user journey, the systems it depends on and the decisions that remain open. That gives the scope discussion a useful starting point: what must work, what could block delivery and what evidence you need before committing.