Who this is for
Owners and operators weighing their first serious AI investment — and anyone who has been asked “why can't we just use ChatGPT for this?” and wants a straight framework for answering it.
Almost every conversation we have starts here. You can pay $20 a month for a capable AI assistant today, so why would anyone pay a consultancy to build something? It is a fair question, and the honest answer is that often you should not. Here is how we think about it.
When off-the-shelf is the right call
Buy the subscription when the task is generic, your data is not sensitive, and “pretty good” is good enough. Drafting emails, summarizing documents, transcribing meetings, brainstorming, first-pass research — consumer AI tools do these well, and no custom work will beat them on price. If that describes your need, we will tell you so.
A recent example. A company came to us wanting a custom internal knowledge hub. When we mapped the data sources that would feed it, 95% of the content already lived in a single platform the team used every day — and that platform's public roadmap showed a native AI assistant shipping within a few months. The remaining 5% could be reached through an integration the platform already offered. Our advice was not to build. The better investment was the capability already bundled into a tool they were paying for.
When you need more than a subscription
The calculus changes when:
- The workflow touches your systems. It has to read and write real records in your ERP, EHR, CRM, or data warehouse — not have someone copy and paste between a chat window and a form.
- Output has to be consistent and auditable. You cannot “regenerate until it looks right” on an invoice, a claim, or a compliance report.
- Your data cannot leave your control. It cannot go into a consumer tool or anywhere near a training pipeline.
- The process runs at volume. Hundreds or thousands of times a day, where a per-seat subscription does not fit and small quality gains compound into real money.
- It needs to live where people already work. Nobody should have to remember to open another tab.
What “custom” actually means
Most of our engagements are not “build a model,” or even “build an app from scratch.” They are integration and orchestration: wiring a capable off-the-shelf model into your process, with the connections, guardrails, and evaluation that make it dependable enough to run your business on. The $20 tool is the engine. We build the car around it.
“What can you do that Claude or ChatGPT cannot do for me?”
A version of the same question. Those tools are excellent at helping one person do one task in a chat window. What they do not do:
- Connect to your systems of record and take action — create the invoice, update the ticket, post to the ledger — reliably and repeatedly.
- Run unattended: triggered by an email, a file drop, or a schedule, with nobody prompting each step.
- Enforce your rules: which sources are authoritative, what format the output must take, what needs human sign-off.
- Give you evaluation and monitoring, so you know accuracy is 94% rather than “seems fine,” and get alerted when it drifts.
- Handle access control, audit logs, and data residency the way your security team requires.
We use the same underlying models. The value is everything around them.
“Can't I just vibe-code it myself?”
“Vibe coding” is building software by describing what you want to an AI coding tool and accepting what it produces without closely reviewing the code — steering by feel rather than engineering. It is real, it is useful, and we encourage teams to use it for prototypes, internal scripts, and throwaway tools.
Where it gets expensive is the last 20%. A vibe-coded prototype that demos well often has no error handling, no tests, security gaps, brittle integrations, and nobody who understands it well enough to fix it when it breaks at 2 a.m. For anything that touches customer data, money, or a workflow people depend on, that last 20% is the whole job.
A sensible split: vibe-code the proof of concept to find out whether the idea has legs, then bring in help to harden the ones worth keeping. We often start from a client's prototype rather than a blank page — it is a good way to begin. It is especially useful for business users who think visually: vibe-coding a rough version of the interface is often a faster, clearer way to show us what they want than sitting through a series of requirements-gathering sessions with a business analyst.