Skip to content

2026-05-02 · 3 min read · WiseChef

Why I Stopped Writing One-Off Skills for Each Client

Three engagements in I had three subtly different codebases, none of which talked to each other, and every upstream change broke all three at once. Here's how I switched to a forkable, version-controlled cookbook — and why integrator economics live or die on this decision.

integrator skills cli automation founder-notes

There’s a moment every AI integrator hits. You’re three engagements in. Each client wanted “basically the same thing, but for our specific case.” So you wrote three “basically the same” projects, each in its own repo, each with its own hardcoded credentials and slightly different connectors.

Then upstream pushes a breaking API change. Now you’re fixing three things in three places at once. Welcome to one-off-skill hell.

I lived there for a few months. Then I changed how I work.

The bespoke trap

The pitch for bespoke is always the same: “the client’s situation is unique, so the build has to be too.” It sounds reasonable. It’s mostly wrong.

Most “unique” client situations are 80% the same problem. Different brand, different data source mix, slightly different output format. The 20% that’s actually different is small enough to fork from a base skill, not large enough to justify a from-scratch project.

The first time I rewrote a CLI for a client because they were on a different platform than the previous client, I lost a weekend. The second time, I lost three weekends and a vacation. By the third I’d seen enough.

The cookbook switch

Now my workflow is:

  1. Every “custom” build starts as a fork of an existing skill from the catalog
  2. The fork lives in version control, not in the client’s filesystem only
  3. Improvements I make for one client get pulled back into the upstream skill (with their permission)
  4. Other clients on the same skill benefit automatically

This sounds obvious in retrospect. It isn’t, and most integrators I’ve talked to are still in the bespoke loop.

A concrete example: the CLI for a horizontal platform

One of my clients runs a high-volume operation on a horizontal CRM-and-ops platform. The web UI is fine for individual operations. It collapses the moment you need to do anything in bulk: move fifty contacts between pipelines, update a custom field across two hundred records, enrol a list of contacts into a campaign.

The client asked: “can you build us a way to do these in bulk?”

The bespoke version of this would have been a custom Python project, integrated against their specific account, run from my laptop, breaking the moment the platform shipped any API change.

The skill version is a CLI. They install it once, configure their API key, and run commands like:

ghl contacts list --tag="hot-lead"
ghl contacts update --field="status" --value="qualified" --filter="tag:hot-lead"
ghl opportunities move --pipeline="Sales" --stage="Closed Won" --filter="value>5000"
ghl campaigns enroll --id="onboarding" --contacts="contact_1,contact_2,contact_3"

Three reasons this beats the bespoke version:

  • Speed. A fifty-contact pipeline update is a few seconds, not ten minutes of clicking
  • Scriptability. Pipe one command into another, schedule the result via cron
  • Auditability. Every command is logged. The client knows exactly what changed, when, and why

The same skill works for the next client on the same platform. And the next.

The economics

Bespoke: hourly billing, capped income, infinite maintenance. Every new client multiplies the maintenance load.

Cookbook: value billing, scalable income, maintenance amortised across all clients on the skill. Every new client increases leverage instead of decreasing it.

The math gets stark fast. A bespoke integrator is back to zero on Monday morning. A cookbook integrator wakes up on Monday with the catalog already shipped.

What changes once you commit to the cookbook

You stop saying yes to “build me a custom thing.” You start saying “I’ll fork the closest existing skill, customise for your case, ship in a week.” Some clients push back. The good ones don’t.

You stop billing for the build and start billing for the install + integration + maintenance. Different invoice shape, much more predictable.

You stop hoarding work. Improvements you make get contributed upstream. Yes, that means other integrators benefit too. That’s how catalogs grow, and a bigger catalog makes you more valuable, not less.

Install path

pipx install wiserecipes
wiserecipes install gohighlevel-cli

ghl config set --api-key="your_key" --location="your_location_id"

Available on the Operator tier ($100/mo).

If you’re an integrator still writing one-off projects per client: try forking instead. One engagement is enough to feel the difference. Three is enough to never go back.

GoHighLevel CLI is one of the platform-specific skills I lean on heavily. The full catalog is at /library.