Before You Build the Automation, Check What You Already Pay For

Before You Build the Automation, Check What You Already Pay For

Before you build an AI automation, first prove that your existing software cannot already do the job. Cheap building has made custom work easy to start and easy to regret. The right sequence is simple: inspect what you own, claim the help attached to it, then build only the thin layer still missing.

THE NEW DEFAULT FAILURE

Why has cheap AI made overbuilding more likely?

Cheap AI has lowered the friction to make a workaround, not the need to understand the problem. In the engagements we run, we watched a long-running custom automation get retired by a fifteen-minute vendor demo. The pain being scripted around was a built-in template feature all along.

That is not a story about a careless team. It is what happens when the first available answer is, “we can build that.” A capable operator sees a repeated annoyance, opens an AI assistant or calls a technical teammate, and has a plausible workflow before anyone has checked the settings already paid for.

The old constraint was development capacity. The new constraint is restraint. A custom workflow still creates surfaces to maintain: permissions, exceptions, changing fields, handoffs, and the quiet question of who notices when it stops behaving as intended. The build may be cheap. The ownership is not.

Build last, not because building is hard, but because maintenance is real.

THE FIRST CHECK

What should you ask before you build anything?

Ask whether the existing system can handle the outcome natively, then make someone show you. “I do not think it can” is not a finding. It is the start of a short investigation.

We keep finding that the duct-taped AI pipeline someone built is already a native setting in software they pay for. The native option is often not advertised in the screen people use every day. It may sit in a template library, a rules area, an admin menu, or a feature released after the original setup.

Start with the actual business outcome. Do not begin with a proposed workflow such as “send this data through an AI step.” Instead ask, “Can the system route this request, standardize this field, create this follow-up, or produce this first draft?” That wording prevents the implementation from becoming the requirement.

Check	Question to answer	Evidence that counts
Native capability	Can the current system perform the outcome?	A live demonstration with your real process
Configuration	Is the feature enabled and set up correctly?	A settings review, not a memory of the original setup
Supported workaround	Is there an approved template or implementation path?	Vendor guidance that accounts for exceptions
Residual gap	What remains impossible or unacceptably clumsy?	A short, specific list of missing behavior

The table matters because “we need an automation” is too broad to make a good decision. Once the residual gap is written plainly, you can see whether it is a genuine gap or a confusing setup problem. Most teams discover some of each.

THE ASK

Why should you make the vendor do some of the work?

You should ask for implementation help because you already bought the right to ask. Most SMBs never went through their vendor’s free implementation program. A healthy account run at a fraction of capacity is the norm.

This is where owner-operators can be strangely reluctant. They assume the help is generic, that a salesperson will not understand the workflow, or that asking will create a sales conversation they do not want. Sometimes it will be imperfect. It is still an efficient way to learn what the product can and cannot carry.

Request a focused working session. Bring one recurring process, the person closest to it, and a written list of the exceptions that create rework. Ask the account team to show the closest native pattern, the setup required, and the tradeoffs. Do not accept a feature list in place of a walkthrough.

Paid-for-help rule. Treat onboarding, training, account reviews, and implementation audits as operating assets. Use them before you create a private system that only your team knows how to repair.

The objective is not to force every process into a vendor’s default. Some defaults are genuinely too rigid. The objective is to make the custom decision informed. If the native path works for most cases and leaves one exception, your answer may be a small manual step, not an elaborate new pipeline.

For teams that want a peer setting to pressure-test those choices, our AI Lab workshops are built around the operating question, not a race to assemble the most tools. The useful output is a clear next move and an owner for it.

THE BUILD DECISION

When is a custom AI workflow actually justified?

Build when you can name the gap, its owner, and the behavior that would make the build successful. “We want to use AI more” is not a gap. “Our current setup cannot turn these recurring unstructured inputs into a reviewable draft without rekeying” might be.

The distinction matters because an AI workflow can appear to work long before it works reliably in the hands of the person who needs it. A tidy demo may ignore ambiguous inputs, unusual requests, approval steps, or the information held only in someone’s head. Those are not edge cases if they happen in normal operations.

At Vista, the framework we use here is Good-Enough-For-You. It asks a deliberately practical question: what is the smallest version that helps this team perform the job with acceptable effort and judgment? It does not ask for a polished system on day one.

That framework keeps the build rough on purpose. Give it one job. Choose a clear human review point. Make the handoff visible. Run it with the people who will live with the output. If the workflow needs continual rescue from the original builder, it has not earned expansion.

A SEQUENCED TEST

What does a sensible decision sequence look like?

The sensible sequence moves from cheap learning to narrow construction. It is less exciting than starting with a clever build, and it produces fewer systems that later need to be unwound.

First, read the relevant documentation and ask the vendor the outcome-based question. Second, shake the tree for the free implementation help embedded in the relationship: account managers, onboarding audits, training, and configuration reviews. Third, define the gap that remains in one sentence, including who owns it and where a human must decide.

Only then should you build. Start with the rough version that proves the missing behavior, not the full vision. Keep the original process available while you test. Watch where people correct the output, delay a handoff, or leave the workflow to finish the job another way. Those observations are your real specification.

This also protects against needless integration. A system connection is not automatically progress simply because the data can move. If the handoff does not reduce a meaningful decision or remove repeated work, it may add more moving parts than value. The same discipline applies in knowing when not to integrate your systems.

THE OPERATOR'S ADVANTAGE

How do you keep this from becoming another stalled project?

Keep the investigation short and give it an owner. The owner is not the person who enthusiastically proposed AI. It is the person who can gather the real process, convene the vendor session, write the residual gap, and say whether the current setup is good enough.

That owner needs permission to conclude that no custom build is needed. Without that permission, the exercise becomes theater. People will search until they find some feature missing, then call the resulting build inevitable.

There is a useful psychological benefit to this order. A team that has learned the native system properly will make a better custom tool later. They know where the data truly lives, which exception cases matter, and which behavior is worth preserving. The build becomes a deliberate extension instead of a replacement for learning.

If a real gap survives the check, do not overcorrect into paralysis. Build the rough AI tool that serves the specific job, using the same Good-Enough-For-You standard. The companion question is how to keep that roughness productive rather than careless, which we cover in building a rough AI tool that is good enough for you.

The verdict is not “never build.” It is more demanding: earn the build. In an era when nearly anyone can create an automation by afternoon, the operator who checks existing capability first is not slower. They are the one who keeps the business simpler enough to improve.

PRACTICAL QUESTIONS

Frequently asked questions

Should I ask the vendor even if I expect a sales pitch?

Yes. Set the scope before the conversation: bring one workflow, ask for a live demonstration of relevant capability, and request implementation guidance. You are gathering evidence, not accepting a proposal. A sales conversation is manageable; rebuilding a feature that already exists is a more expensive distraction.

What if the native feature only handles most cases?

Most cases may be enough if the exceptions are visible, low risk, and owned by someone who understands them. Keep the native flow for the repeatable work and define a manual exception path. Build custom automation only when the remaining gap materially burdens the people doing the job.

Does a rough build mean an unreliable build?

No. Rough means narrow in scope, clear in purpose, and honest about the human review it needs. It should handle one useful task and expose its limits. Reliability comes from observing real use, not from adding every possible feature before anyone has tested it.

Who should own the pre-build check?

The owner should be close enough to the process to recognize exceptions and empowered enough to convene the needed people. It may be an operator, manager, or systems owner. It should not be a detached sponsor who cannot decide whether the current workflow is acceptable.

When does an integration deserve to be built?

An integration deserves to be built when it removes a defined recurring burden that native features and a simple handoff cannot solve. Write down the missing behavior, the data involved, the review point, and the long-term owner. If those are vague, the integration is not ready.

What is the fastest way to start this process?

Choose one repeated annoyance, describe the desired outcome without naming a tool, and book a focused configuration conversation with the vendor. Ask what is native, what help is available, and what remains unsupported. That short check gives you a disciplined basis for either stopping or building.