Beyond Zapier and ClickUp: What the First Step Toward Custom Automation Actually Looks Like

The signal that a business has outgrown Zapier and ClickUp isn't a specific volume of tasks — it's when the automation itself starts fighting the tool: workarounds stacked on workarounds, a single change needing edits in six places, or a report that needs data joined from three systems with no native way to do it. The first step toward a custom build is never "hire a dev team and rebuild everything." It's a narrow, working prototype of the one workflow actually causing pain, built fast with modern AI coding tools, and judged against the off-the-shelf tool it's replacing before anything wider gets committed to.

I'm Jack Lenton, a ClickUp Verified Consultant and Zapier Silver Solutions Partner running Toki, an automation consultancy based in Norwich. Most of what I build stays inside ClickUp and Zapier — but it's worth being honest about where that stops being true, and what a sensible first step looks like when it does.

What are the actual signs you've outgrown Zapier or ClickUp?

Workaround stacking is the clearest one: a Zap that's grown five extra steps to handle edge cases the original trigger never anticipated, or a ClickUp Automation chained to three others just to get one status change to behave. Reporting that needs data joined across systems — ClickUp plus a CRM plus an accounting package — is another, since neither platform is built to query across a boundary it doesn't own. And a client-facing need the tool simply wasn't designed for, like giving an external party a live view of their own data without handing them a seat, is usually the final push.

What does "custom build" actually mean day to day?

Rarely a full bespoke application built from nothing. More often it's a thin custom layer — a small script, a lightweight database, an API connection — sitting alongside ClickUp and Zapier, handling the one specific thing they can't, while everything else stays exactly where it is. The goal isn't to replace the automation stack that's already working, it's to patch the one gap that's genuinely outside it.

Why is the first step cheaper than it used to be?

AI coding tools — Claude Code, Cursor and similar — have lowered the cost of a working prototype significantly. A small, well-scoped custom tool that used to need a developer sprint and a proper brief can now be built and tested in days by someone who understands the problem, even without a background in software development. That changes the calculus: the first step no longer needs a five-figure commission before you know if the idea holds up.

What should the first step actually be?

1. Name the one workflow causing the pain — not the whole system. If you can't point to a specific process, you're not ready to prototype anything yet.
2. Prototype only that, outside your live tools. Build it as a standalone test, not a change to production ClickUp or Zapier, so nothing that already works is put at risk.
3. Run it in parallel against the current process for a defined period — a few weeks is usually enough to see whether it's actually better, not just different.
4. Decide based on that comparison, not on the fact that something's already been built. A prototype that doesn't clearly beat the old process is a result, not a failure.

When should you keep it simple instead?

Most businesses don't need custom software, and that's worth saying plainly. ClickUp and Zapier cover the large majority of workflows a small or mid-sized business runs, and reaching for a custom build because it feels more sophisticated — rather than because there's a specific, named gap — usually adds maintenance burden without adding value. Custom is for the outlier that off-the-shelf genuinely can't do, not a general upgrade path.

Frequently asked questions

How do I know if my business needs custom automation?
If you can point to one specific workflow that off-the-shelf tools can't handle — not a general feeling that you've "outgrown" your stack — that's the signal. A vague sense of complexity usually means a ClickUp or Zapier reconfiguration, not a custom build.

Do I need a developer to build a custom automation prototype now?
Not necessarily for a narrow first prototype. AI coding tools have made a small, well-scoped test achievable without a dedicated development team, though a production-grade build handling real client data is still worth getting proper technical input on.

Should I replace ClickUp and Zapier with a custom system?
Almost never wholesale. The usual pattern is a thin custom layer sitting alongside the existing stack for the one thing it can't do, not a full replacement of tools that are already working.

Almost done! When you're ready, here are four ways I can help you:

1. Read it. A guide on how to use ClickUp and actually make it work for you.
2. Connect it. Let's be LinkedIn pals. I make funny videos sometimes.
3. Workshop it. Book a 30-minute chat to talk processes and build a Miro together.
4. Go for it. Fill in my contact form — let's talk ClickUp or Automations. Whatever tickles your pickle.

Wanna hear from the unfiltered version of me? Sign up to my newsletter. The Working Notes. 2 minute reads. Behind the scenes. Hopefully helpful. Maybe funny.