For an owner without a developer: describe the result, not the code change

Start with one observable result

Describe what a person should be able to do and what happens instead: submit a booking and receive its message, log in and reach a report, or keep old mail while new mail reaches the new service. You do not need to diagnose a framework or specify a pull request. A public link and redacted screenshot often convey the symptom better than guessed technical instructions.

• Name the affected flow and when it last worked.
• Record the preceding host, app or version change if known.
• Say what would count as a successful result you can inspect.

Authority is different from technical labour

You retain control of the business accounts and approve changes, but that does not mean you must operate GitHub or manage individual coding sessions. The proposed delivery route must name who can safely run the copy, review the work and perform any approved live step. Synthetic Industry resolves its fulfilment route before accepting work; unresolved access is a blocker, not a request for your password.

• No credentials, private code or account invitations in first contact.
• Identify who owns the software rights and relevant provider accounts.

Ask for evidence you can use

For UI work, ask for the agreed running flow and relevant screenshots. For a background process, ask for a runnable synthetic example and its expected result. For company-seat signup, specify who may invite users, the permitted seat count, and what happens at the limit; require synthetic below-limit, at-limit and unauthorised-invite checks rather than assuming an account exists means company permissions are correct. These are proposed acceptance checks, not a claim about Bubble's built-in seat limits. The handover should explain changes, checks, review findings and limitations in plain English. A successful command or green badge alone may not prove your business outcome.

• Keep acceptance and production approval distinct.
• Agree scope and price before any private work or charge.

When the job becomes larger

A one-off repair is appropriate for a bounded failure. Repeated changes can fit a scoped backlog project or engineering lane after fit is confirmed. Legacy conversion, mailbox migration and a host move have different data and recovery boundaries; do not bundle them into an assumed small fix without a written scope.