What to ask a technical partner before approving delivery

Use a specific blocked integration to test the conversation

Consider a fictional invoice-summary project. The proposed first release is a CSV for the current organization, with an agreed date range and column names. Scheduled email and a custom report designer are excluded. These are invented scope assumptions for this example, not a client story or an Ulties offer.

Assume the team has a preview built from synthetic records, but access to the accounting provider’s sandbox is still unavailable. A preview can support discussion of columns, empty results and error wording. It cannot establish that live authentication, invoice mapping or account permissions work. No prototype or integration was executed for this article.

The client’s stipulated immediate need is a supervised month-end pilot, not continuously updated reporting. A finance owner must confirm the meaning of the columns and totals. An engineering owner must establish the permission boundary and source-system behavior. Naming those decisions prevents a polished screen from silently becoming approval of the data behind it.

Replace “on track” with a scoped update and two choices

Here is a proposed update for that fictional situation: “The review is limited to the synthetic CSV preview: column names, empty results and error wording. Live authentication, source totals and access across organizations remain unverified because sandbox access is blocked. We need the finance owner to confirm the columns and the project owner to choose the pilot’s data route before we commit to an integration delivery plan.” This is sample wording, not a report of completed work.

Option A is a supervised manual-file pilot. An authorized operator obtains a source export and checks its coverage before using it for the preview. The pilot must show which file and reporting period it uses, rather than present the figures as live. This avoids making the pilot depend on sandbox availability, but it adds manual work and opportunities for stale or incorrectly selected input. Use synthetic or approved de-identified input until access checks are verified; choosing a manual route does not authorize loading customer records into an unverified preview.

Option B is to wait for the provider connection. That avoids introducing a temporary manual route, but the integration scope remains uncertain until the team can inspect authentication, representative responses and failure behavior. The team should not convert an unavailable sandbox into a confident fixed completion date.

Under the stated assumptions, my recommendation is Option A for the supervised pilot, with production integration approval held back. The reason is that the immediate question is whether the agreed report supports reconciliation, while fresh automated data is not yet a fixed requirement. If the client needs unattended reporting or cannot safely manage source files, Option A fails those constraints and the recommendation changes.

The completed decision for this exercise is therefore: retain the preview scope, use a manual-file pilot, keep the live connector outside pilot acceptance and revisit the choice when representative sandbox access exists. The project owner must authorize the route in a real engagement. The hypothetical choice here is not evidence that a client approved it, that it is secure, or that it saves time or money.

Make acceptance match the route you chose

For the proposed pilot, finance should agree a reference file, its reporting period and the expected interpretation of each total. Ask engineering to demonstrate that another organization cannot retrieve the output, that an empty result is understandable and that a failed operation does not expose internal details. Those are proposed acceptance checks, not passed tests in this article.

Do not accept “retryable” without asking what a repeated action does. Does it create another report, reuse the existing one or read a changed source? A manual route also needs a procedure for choosing the correct source file and correcting a mistake. The pilot’s acceptance record must preserve the unverified connector work instead of implying it disappeared.

Include the actual browser interaction in the review. W3C’s Easy Checks covers preliminary checks such as keyboard access, visible focus, labels and understandable errors. W3C explicitly cautions that this first review is not a complete accessibility assessment. Use it to find obvious barriers, then agree the fuller evaluation the project requires.

Keep ownership and support out of the assumptions

My recommendation is to agree account control and support responsibilities while choosing the delivery route. Identify who can access the repository, hosting, domain and monitoring accounts. Record who can change permissions, recover access and take over when the usual contact is unavailable. Contractual ownership and licence terms need an explicit agreement; an account-access checklist cannot establish them.

Ask the intended support person to follow recovery instructions in a test environment. For this example, the exercise should include an incorrect source file and a failed report. Record what they could diagnose and when they needed help. This is proposed handover work, not a claim that a runbook has been tested or that ongoing support is included in Ulties pricing.

A technically impressive partner can still be a poor fit if this decision process is too slow for the work you need. Ask for a small example update before agreeing a large project. Judge whether it exposes a meaningful uncertainty and gives you a choice you are equipped to make. The engineering team should retain implementation responsibility rather than delegate unexplained technical decisions to you.