Start with no-code, unless you have a reason not to
Connector platforms are quick to set up, visible to non-developers and easy to change. For routing form leads, sending acknowledgements, creating CRM records and scheduling reminders, they are usually enough. The question is not "which is better" but "has this workflow outgrown a connector?"
Signals that a connector is enough
- Each workflow is a short chain: something happens, a few things follow.
- The apps involved have maintained integrations that support the exact triggers and actions you need.
- Volume is modest and predictable.
- The person who'll maintain it can read the workflow and understand it.
- Failures can be noticed and fixed within a business day without serious harm.
Signals that you may need custom work
| Signal | Why it matters |
|---|---|
| A key app has no integration, or the integration lacks the action you need | You'd be bolting raw API calls onto a no-code tool anyway |
| Complex branching, loops or calculations | Visual workflows become hard to read and test |
| High or spiky volume | Usage-based pricing and rate limits can bite |
| Strict ordering or exactly-once requirements (payments, inventory) | Needs careful duplicate handling and state; see payment webhooks |
| Sensitive data with specific handling rules | You may need control over where data is processed and stored |
| The workflow is core to how you earn money | It deserves version control, tests and monitoring |
One signal alone isn't decisive. Two or three together usually are.
What "custom" should mean for a small business
Custom doesn't have to mean a large software project. Often it's a small, well-documented piece: a webhook receiver that verifies payment events, a scheduled job that syncs two systems, or a script that cleans data before import. Ask for:
- Code in a repository you own or can access.
- Plain documentation: what it does, where it runs, how to restart it, who to call.
- Logging and alerts for failures.
- Credentials stored in a secrets manager or the hosting platform's secure settings, not in the code.
- A test or sandbox mode.
Security basics apply to small code too. The OWASP Top 10 is a widely used overview of common web application risks that whoever builds it should know.
Costs to compare honestly
- Build: connector setup time versus development time.
- Running: connector subscription and usage versus hosting.
- Maintenance: connector workflows break when apps change; custom code breaks when APIs change. Both need an owner.
- Exit: how hard is it to move away later? Documentation reduces this for both.
Make the decision visible
Whichever you choose, write it down: why this approach, what would make you revisit it, and who owns it. That record is part of the automation runbook and saves the next person from guessing.
Questions
Is custom always more expensive?
Usually more expensive to build, sometimes cheaper to run at high volume, and it needs someone who can maintain code. Compare the total over a realistic period, including maintenance, not just the build quote.
Can I mix both?
Yes. A common pattern is a no-code platform for most workflows, with one small custom piece — for example, a webhook receiver — where the connector falls short.
Sources and further reading
- OWASP Top 10 owasp.org
Official documentation changes. Check the current version before you rely on a rule, limit or setting.
Next step
Start with one workflow worth fixing.
Bring the real steps, the tools you already use and the place the handoff gets stuck. We review feasibility, access and approval points before quoting — no instant integration promise.
See Business Automations for what we scope, or prepare a custom quote brief.