A tool, a build or a managed service?

What needs to connect?

A platform can be a good starting point for a well-understood workflow between supported applications. Check whether the required triggers, actions and data are available, and whether someone on your team can maintain the setup.

A custom build becomes useful when the interface, data model or business logic needs more control. A developer or agency can help deliver that work. The scope should include how the system will be documented, tested and handed over.

Who will run it?

A managed arrangement adds responsibility for an agreed operating scope after launch. Confirm what monitoring, support and changes are included, how exceptions are handled and which third-party costs remain separate.

Decide how much of the infrastructure your team wants to operate. Make the responsibilities concrete: agree account ownership, data access, maintenance and what happens if you later change providers.

Compare the full commitment

Compare setup, recurring service fees, usage costs and internal time using the same workflow description. Generic price ranges and promises about how quickly a category of supplier works are poor substitutes for a scoped proposal.

Describe the input, the expected result, the systems involved and the point where a person makes a decision. That gives each option something useful to answer.

• Required connections and complexity
• Internal skills and available time
• Ownership, maintenance and total ongoing cost

Compare who owns the work

Use the same task and operating period for each option. Ask for responsibilities in writing.

• A supported tool: your team configures the workflow and handles the exceptions, unless another arrangement is agreed.
• A custom build: the proposal defines the software, delivery checks, account ownership and handover.
• An ongoing service: the agreement also defines monitoring, support, changes and usage costs.