Say what should be true afterwards
Connect the app to the service is not a result; it describes a means. A result is something you could check on a Tuesday: the agreed event sends one text to my phone and the app records that it arrived; a booking made in the app appears once on the staff calendar at the right local time; a customer who picks an address suggestion gets the town and postcode filled in. Write one sentence like that for the connection you want. If you cannot say how you would check it, the scope is not ready.
- Name the event or action that starts it.
- Name the place where you will look for the result.
- Say what must not happen: no duplicates, no lost enquiry, no change to production.
Decide who holds what
The accounts, credentials and recipient data stay yours. For a first conversation you need to know which account exists, who can create a restricted key or a test credential, and whether a staging copy of the app exists. You should not send keys, passwords, customer lists or code in a first enquiry; those arrive, if at all, after scope is agreed and only in the narrowest form: a staging credential you create, never the production key.
- Ask for restricted staging credentials rather than sharing a login.
- Keep the production credential in your secret store.
- Some behaviour needs a live test on your own phone or mailbox because a provider's test mode cannot show it.
Match the need to one outcome
Each connection below is a separate bounded result with its own test: transactional email through SendGrid with bounces recorded; an SMS for one event through Twilio with delivery status; one event alerting a Slack channel; bookings written to Google Calendar; address autocomplete on a form; Sign in with Google added next to your login; a Slack events endpoint that is verified and replay-safe; direct file uploads with signed links; website enquiries pushed to Pipedrive; and hardening one API client's retries. Prices are untested test prices, fixed or from a stated starting figure, with payment after the agreed checks pass and you sign off.
- More than one connection at once: ask about the notification project or a consolidation project.
- Something already built and failing: say so, because a repair may be smaller than a build.
- If the first answer is that the service has no way to test the behaviour safely, say that too.
What happens next
An enquiry by email starts a conversation, not a booking. You describe the result, the stack and who holds the account. If it fits, scope, checks and an access route are written down before anything is touched. Work happens on a branch or copy you control, with human review points named in the agreement, and you merge and deploy under your own rules. These are new services with no client delivery record yet, which is why the checks are written to be inspected by you.
- No payment before sign-off for a fixed job.
- You can walk away at any point before work starts.
- Nothing is deployed to your production by us.
Sources and limits
- Google Calendar: create events Checked 2026-10-11.
- A client-supplied event ID prevents duplicates if a call fails partway, which is an example of a failure mode a connection must be tested for.
- Twilio: test credentials Checked 2026-10-11.
- Messages sent with test credentials do not trigger status callbacks, so some behaviour can be tested only with a live send to your own phone.
- Slack: Web API rate limits Checked 2026-10-11.
- Providers publish limits such as about one message per second per channel that a connection must respect.