Who controls source and production?
Name repository, hosting, DNS, identity, analytics, payment, email, data, vendor, release, and rollback owners. The client should retain or deliberately delegate every critical account.
Buyer control / evidence before promises
Score the delivery relationship, not the sales presentation.
A remote vendor can demonstrate technical capability without being the right operating fit. Use this scorecard to test who controls source and production, how South Africa-facing users and approved requirements are represented, what evidence accompanies a release, and whether the client can operate after handoff.
Which South Africa-facing users are represented?
Require approved evidence for role, location, language, device, accessibility need, network condition, support route, and the job the service must complete. Avoid universal claims.
Who defines data obligations?
Qualified client advisers define applicable POPIA, sector, security, retention, transfer, rights, incident, and contract requirements. The vendor maps approved requirements to fields, access, logs, vendors, and tests.
Can money and status be reconciled?
Separate display currency, contract, tax owner, provider, authorization, settlement, fulfilment, refund, dispute, failure, retry, and reporting. Ask for a controlled failure-path demonstration.
What proves a change works?
Expect changed-source identity, environment, build and migration record, acceptance checks, browser and device evidence, integration validation, error behavior, analytics identity, rollback, and observation window.
Can another team operate it?
Require decisions, architecture boundaries, account ownership, deployment and recovery instructions, known risks, vendor dependencies, support scope, backlog, and evidence that the client can access the delivered assets.
0–3 rating
Attach evidence to every score.
0 unknown: no owner or proof. 1 promised: described but not demonstrated. 2 defined: owner, rule, and artifact are documented. 3 verified: the relevant user, owner, system, failure path, or release has been tested in the intended environment. A critical zero should remain visible even when the total is high.
Interview prompts
Ask for the behavior behind the answer.
- Show how a new maintainer receives source, access, environment, release, and rollback knowledge.
- Show how a requirement from a South African authority or qualified adviser becomes a testable implementation rule.
- Show a failed integration, duplicate action, slow request, interrupted transaction, and the operator response.
- Show which analytics and lead events identify the exact property, page, and outcome without exposing protected data.
- Show what the vendor cannot responsibly guarantee and how adoption, search, leads, or revenue will be measured after release.
Use the weakest critical control to define the first milestone.
A narrow authority, data, transaction, release, or handoff milestone is more useful than a broad promise to “build the platform.”