Tools, Vendors, and Advisors | Blane Canada

Question 1

Should we buy an AI product or build a custom solution?

Accepted Answer

Buy when an existing product solves the requirement well at acceptable cost and risk. Build when the opportunity depends on your specific processes, information, or integrations, and no product can address them without forcing you into compromises. The decision follows discovery. It should never be a preference held in advance.

There is no strategic virtue in custom development for its own sake, and there is no safety in buying either. Both are architecture decisions that should come after you know what has to be accomplished.

The case for buying is strong when a mature product covers most of the requirement, integrates without heroics, satisfies your security obligations, and is economically sensible. You get faster deployment, established support, and a vendor who keeps developing the product without billing you for it. That is a good deal when the fit is genuinely there.

The case for building gets stronger when the workflow is distinctive, when the information has to be assembled from several systems you already own, or when the process itself is part of why customers choose you. In that situation a packaged product forces you to change how you work in order to match how it was designed, and the compromise costs more than the software saved.

Two things that belong in the comparison and usually are not. First, lifecycle economics rather than build cost. A custom system brings maintenance, governance, and support obligations you now own. Second, the practical support question. One client's requirements list included manageable maintenance with limited internal support, and that single constraint eliminated several otherwise attractive designs.

There is also a middle path worth knowing about. Proving a concept cheaply with low-code tools and then rebuilding properly for production is two different jobs with two different skill sets, and treating them as one is where a lot of builds go wrong.

Question 2

Do we actually need AI for this, or would something simpler work?

Accepted Answer

Ask that question about every project, and be willing to accept the answer. Sometimes a straightforward database application, a process change, or better reporting solves the problem faster, cheaper, and with less maintenance than an AI build.

Simplify first. Non-AI solutions are often the better answer, and any advisor who cannot say that out loud is selling rather than advising.

We had a client convinced they needed AI for proposal responses. The pain was real and measurable: matching prior answers to incoming questions took days, and a complicated proposal took two weeks or more. Their requirements included low cost, manageable maintenance with limited internal support, and strict confidentiality.

The best solution turned out to be a database application doing structured data matching, with AI used narrowly to find semantic relationships between questions and answers rather than a keyword match. Less impressive to describe. Dramatically better on every requirement they actually had.

So the question worth asking yourself is whether you are willing to accept the simple solution, or whether you want someone who will complicate it so you can say you have an AI application.

Before you commit, run three tests. Would a process change alone fix most of this? Is the underlying task structured and repeatable enough that rules would handle it? Is the data messy and variable enough that it genuinely requires interpretation? Only the last case clearly calls for AI.

Question 3

Why am I getting pitched so many different AI solutions, and how do I tell them apart?

Accepted Answer

Because four different things are being sold under one label. A consultant to help your team use AI day to day. A point solution for one defined problem. An upgrade to software you already own. And a full transformation. All four are real, all four are positioned as urgent, and all four are in your inbox.

Once you see the four categories, the noise resolves into something you can evaluate.

The first is help using the tools. A consultant or vendor who trains and supports your team in daily use. This is the lowest cost of the four, the fastest to show an effect, and often the right first step, because it builds the internal judgment you will need to evaluate everything else. It is also the one most likely to be dismissed as insufficiently ambitious, which is usually a mistake.

The second is a point solution. One specific operational fix, built or bought to address a defined pain point. These come from outside vendors and just as often from inside, pushed by a department head who has already decided what they want. A point solution is a good investment when the pain is real and measurable, and an expensive one when the department was solving a symptom.

The third is an enterprise software upgrade. Your existing platforms already have AI built into them. Some of it is genuinely useful and some of it is not, and the pitch is always that you are leaving capability on the table. The advantage here is real: your data may already be protected at an enterprise level and your people already know the interface. The risk is paying for capability nobody asked for.

The fourth is transformation. A platform or operating model that repositions how the organization works at scale. This is the largest commitment, the longest horizon, and by far the hardest to reverse, which means it should be the last of the four you consider rather than the first.

The pressure is not random. It is structural. When a technology wave moves this fast, every provider reconfigures their pitch to match the moment. The label changes. The underlying product often does not.

That is not a reason to ignore AI. It is a reason to pause long enough to understand which of these four actually fits where your organization sits, before the next meeting starts. Most executives do not get that pause. That is where the waste starts.

Question 4

What questions should I ask before signing an AI contract?

Accepted Answer

Five. Does this solve a specific problem we have identified? How will success actually be measured? What is the real implementation cost? What happens to our data? And what is the exit strategy if it fails? The first one is the key, and it is the one most often skipped.

Executives tell me constantly that they are getting pitched AI tools every day and have no idea how to evaluate them. We see it in our own inbox. Another assistant, another automation platform, another tool promising large productivity gains. It is noise.

The biggest mistake companies make is buying tools before clearly defining the problem they are trying to solve.

Question one is the filter that eliminates most of the field. If you cannot state the problem in one sentence without using the vendor's language, you are not ready to buy anything. The test is harder than it sounds, because a good pitch supplies you with vocabulary that feels like clarity. Try describing the problem to someone in your own company who was not in the meeting.

Question two protects you a year from now. If nobody defines success before deployment, nobody can defend the investment when budgets tighten, and the initiative disappears without anyone deciding to end it. Write the number down before you sign, and make sure it is a business number rather than a usage number.

Question three is about the run, not the build. Ask for ongoing operating cost at the volume you would reach if this actually worked, because usage-based pricing means success raises your bill. Add the data preparation nobody scoped and the training that determines whether anyone adopts it.

Question four matters more than most executives realize, and it matters most in professional services. Where does your information go, who can see it, is it used to improve the vendor's product, and what happens to it if you leave? For a firm with client confidentiality obligations, that last part is not an IT question.

Question five is the one nobody asks in an enthusiastic first meeting. If this does not work in nine months, what does it cost to leave, and what do you take with you?

Do not start with the tool. Start with the assessment. Sometimes the answer is AI. Sometimes it is a simple process fix.

Question 5

How do I tell a real AI expert from someone selling hype?

Accepted Answer

Ask what business roles they have held. A great many AI experts have never sat in a leadership seat, never signed off on a profit and loss statement, and never cleaned up after a half-finished implementation. Their solutions are looking for a place to land. Do not be that place.

The illusion is real, and business leaders are the ones left holding the bag.

The pitches are consistently impressive. Chatbots that sound human. Smart workflows that run your operation. Scoring tools that predict your next customer. Here is the part nobody wants to say out loud: a lot of what is sold as AI transformation is a magic act. It looks slick in a demonstration. Try to scale it in the messy, complex world of real customers and real operations and it breaks, invents facts, and introduces reputation risk.

As business owners and managers, we do not get to enjoy the show. We have to deliver results and protect the bottom line.

The screening questions are not technical. Have you run a business? Do you understand what my operation actually does? Can you explain what could go wrong with this and who owns it when it does? Would you tell me if the right answer here is not AI?

Someone with real business experience knows the difference between cash flow and making payroll, and knows that a solution which disrupts a critical process has cost more than it saved. Someone without it can offer many novel solutions to imagined problems.

Question 6

Should I hire a developer or a consultant to lead our AI work?

Accepted Answer

Both, in the right order. Developers build. Advisors make sure the build solves the right problem. Hiring a developer to set your AI strategy is like hiring a plumber to design your house. The pipes will be excellent. The roof is a different discipline.

Most of the AI builds we get called in to fix had solid code and broken thinking. No discovery, no impact analysis, no business case. The developers were not wrong. They were the wrong role for that part of the work.

You cannot code your way out of a business problem nobody understands yet. Proper discovery means understanding the ripple effect of automation on people, processes, and customers, and being in the room where strategy happens rather than being handed a specification afterward to execute.

Developers deliver what you ask for. An advisor challenges why you are asking. Both are necessary. The order is what determines whether you get value.

What discovery has to produce is a description of the business requirement specific enough for a builder to work from. Which part of the process. What currently consumes the most time. What information is confidential. Who approves the output. What would count as improvement. Hand a developer the instruction to use AI to improve proposals and they have to fill in every one of those gaps themselves, usually by guessing. Discovery also has to involve the people doing the work, because they know the exceptions and workarounds that never made it into anyone's process document.

There is a second reason the sequence matters, which has to do with how the build itself is staged. Proving a concept cheaply and building something that can carry real production load are two different jobs requiring two different skill sets, and they need to happen in that order and on purpose.

Question 7

Do we need to buy new software, or can we get value from what we already own?

Accepted Answer

Usually not, and the question hides a third option. You can buy something new, you can connect what you already own, or you can build a layer that sits on top of what you own and holds context over time. The third is the least offered and often the most valuable.

The question almost always arrives as a binary, and the binary is what drives the overspending. Buy a platform, or make do with what you have. There is a third answer that no vendor has a reason to raise with you, because nobody sells it off a shelf.

Connect what you already own. On one distribution engagement, an executive was losing more than half of every working day to route planning, with late fees waiting behind any stop that slipped past its verification window. What fixed it was not a purchase. It was connecting three systems the company already had, so the risk surfaced early enough to act on. That kind of work costs a fraction of a platform, with no migration, no retraining, and no new vendor relationship.

Build a layer on top of what you own. This is the one that gets missed. On a fleet engagement the visible deliverable was a weekly performance report. The part that mattered was underneath it: every metric stored as a permanent record, one row per driver per day, with the chronological detail of every stop. The report is what you look at. The record underneath is what made the next phase possible, because the system could then surface problems on its own instead of waiting for someone to go looking.

That distinction is the whole argument for infrastructure over purchase. A tool you buy performs about the same on day four hundred as it did on day one. A layer you build gets more useful every month, because it is accumulating a record of how your operation actually behaves. Nobody can sell you that, because it is specific to you.

The same logic applies to one person. The Executive Assist Engine is this pattern at the individual level. It does not replace your email, your calendar, your customer system, or whatever platform your team standardized on. It sits above them, holds your operating context, and runs the layer you are currently running out of your own head. Executives tend to ask whether they need to buy something. More often what they need is a layer over what they already have.

None of which means never buy anything. If a mature product covers most of the requirement and integrates cleanly, buying is the obvious answer and building it yourself would be vanity. The point is to work the options in the right order: connect first, build the layer second, buy when neither of those gets you there.

Before adding another platform or another dashboard, find out what your current systems already know and are not telling you.

Question 8

Should we standardize on one AI platform or use several?

Accepted Answer

Standardize on a small sanctioned set rather than on one tool or on twelve, and avoid long contracts while the market is unsettled. Committing to a single provider for years right now is a bet on a landscape that has not settled. Letting every team choose freely is the problem you are trying to solve.

This is a genuinely difficult question and anyone who answers it with confidence is oversimplifying.

The case for standardizing is strong. Different teams using different tools for the same work produce different answers to the same question, and nobody can tell which is right. Costs multiply quietly across subscriptions nobody tracks. And the security exposure of an uncounted set of systems is its own problem.

The case for caution about long commitments is also strong. The landscape is moving month to month, and picking today's winner for a multi-year term is a bet on a market that has not settled. Some technology leaders are handling this by deliberately refusing long-term AI contracts and staying flexible, on the reasoning that it is hard to know which providers will end up on top.

For a mid-sized company, the practical position is usually in between. Standardize on a small sanctioned set rather than one tool or twelve. Be clear about which work is done where. Keep your own data and your own records in a form you can move. And when you sign anything, know what leaving costs.

Question 9

Should the firm that diagnoses our AI opportunity also build the solution?

Accepted Answer

It can, but ask about the incentive before you engage. A firm whose revenue depends on the build has a reason to find one. What matters is not whether they build, but whether they have ever delivered a finding that pointed away from a project, and whether they can name one.

This is the sharpest question an executive can ask in a first meeting, and very few ask it.

The concern is not dishonesty. It is structure. When the same firm diagnoses and builds, the diagnosis is upstream of their largest revenue opportunity. That does not guarantee a distorted finding, but it does mean the pressure runs one direction, and pressure that runs one direction long enough eventually shows up in the work.

There are real advantages to keeping it together. The people who examined your operation understand it, so nothing is lost in a handoff. Accountability sits in one place when something does not work. And a firm that has to live with its own recommendation is more careful about making it.

So the question to ask is not "do you also build?" It is this: tell me about a time your assessment concluded that the client should not build anything. If the answer is vague, or if it has never happened, you have learned what you needed to know. If they can name the engagement and explain what they recommended instead, the incentive is being managed.

For what it is worth, our own answer to that question includes a client who was certain they needed AI for proposal responses and got a straightforward database application instead, because it was cheaper, easier to maintain, and better for their confidentiality requirements. That is the test, and it is a fair one to put to anyone.

Question 10

Can I trust a vendor demonstration?

Accepted Answer

Trust what it proves, not what it implies. Demonstrations look flawless because they run on demonstration data that was packaged to make them look flawless. Your data is different. Ask to see the tool run on a sample of your actual, messy information.

Demonstrations excel at looking good, and that is by design rather than by deception. A vendor prepares clean, well-structured, representative data because that is what shows the capability clearly.

The problem is that the gap between that data and yours is precisely the work you will be paying for, and it is invisible in the meeting.

When we build for clients, we use their actual data from day one. The results are still impressive. They are also honest, because you get to see what it will take to make your information usable and how the system behaves when the input is imperfect.

There is a related pattern worth watching for. I test-drove a prospecting tool recently that had real potential and generated leads quickly with a lot of useful information. The marketing claimed a task took two minutes. In practice it took closer to twenty, largely because there were no parameters for refining a general search. The tool was not misrepresented in what it could do. The time claim simply did not survive contact with a real workflow.

Ask two things of any demonstration. Run it on my data. And walk me through what happens when the input is wrong.

Question 11

How can I evaluate a potential AI partner without a large commitment?

Accepted Answer

Book a custom training session for your team. Low cost, limited commitment, and a group setting that functions as an extended interview. Insist on training built around your business case rather than an off-the-shelf package, and watch carefully whether they can do it.

This is the lowest-risk evaluation move available to an executive, and it produces information no sales meeting will.

The trick is in the customization. Do not accept the standard package. Ask for training shaped around your actual business and your actual use cases. If they cannot do it, you have learned three things. They may not be built to communicate with people who are not technical. They may be steering you toward a rigid, prepackaged solution. Or, in the worst case, they cannot provide clear support for the tools they build.

You also get something of value regardless of what you conclude about the vendor. Your team learns something useful, and you get to watch how outside experts interact with your people, which tells you a great deal about how an implementation would go.

The additional screening questions are simple. Do they understand your business? Do they understand you? Not all developers are equal, and not all development firms bring any layer of business experience with them.

Question 12

Why does the same AI tool give a different answer to the same question?

Accepted Answer

Because it predicts rather than retrieves. A language model constructs each answer word by word based on probability and pattern, so the same input can produce different output. That is a property of the technology, not a defect, and the remedy is to constrain the request.

This surprises executives more than almost anything else, and it undermines trust quickly when nobody explains it.

These systems do not look up an answer and hand it to you. They generate one, predicting what should come next based on patterns in the material they were trained on. That is math, not comprehension. It feels like understanding because the prediction is very good, but it is a different thing.

Once you grasp that, several practical conclusions follow. Variation in output is expected, so if you need consistency you have to build it in through structure rather than hoping for it. Confidence in the output tells you nothing about accuracy, because fluency and correctness are produced by the same mechanism. And the quality of your input matters more than it would with a search engine, because you are shaping a construction rather than filtering a set of results.

Give it a clear task, a defined role, and real context, and you dramatically improve your odds. Details matter.

Question 13

Can we trust the AI features already built into the software we own?

Accepted Answer

Judge the fit, not the label. An embedded AI feature does not make a tool suitable for a job it was never designed to do. We have seen a platform forced into a use case it was not built for deliver results that were roughly a quarter useful, with the rest defended as commitment to a decision.

The situation is common enough to be worth naming. A widely used platform had been mandated as the system for everything, including a use case it was never designed to handle. The person responsible for enforcing adoption held the line with a simple argument: the platform has AI built in, so we can do this.

The executive's assessment was blunt. The tool was delivering results that were about 25 percent useful for the purpose it had been forced to serve. Seventy-five percent waste, defended as commitment to a decision.

Built-in AI is often genuinely useful, and it has real advantages: your data may already be protected at an enterprise level, and your people already know the interface. Those are not small things.

What it does not do is change what the underlying product was designed for. The test is the same one you would apply to any tool. Was this system built for the job I am asking it to do? If the honest answer is no, an AI feature will not close that gap. It will just make the mismatch harder to see.

Question 14

What is AI vendor lock-in, and should we be concerned?

Accepted Answer

Lock-in is when your data, workflows, and integrations become dependent enough on one provider that changing platforms turns into an operational project rather than a purchasing decision. Some dependence is unavoidable. The problem is accumulating it without noticing, which is the normal way it happens.

Every technology decision creates some switching cost. The concern is not commitment. It is commitment that was never actually decided.

The pattern is gradual. Documents connect. Then databases. Then workflows, then automated processes, then security controls, then the way your people work. No single step looks like a strategic commitment. Eighteen months later, moving would mean rebuilding rather than migrating.

One industry leader described the early economics well: the barrier to entry is almost nothing, and if your control system is built entirely inside one provider's toolset you are effectively renting a cage. The speed of the early pilot conceals technical debt that only becomes visible when you try to move the work somewhere else.

There is a newer version of this worth watching. As providers take over more of the surrounding infrastructure, including the stored memory of what your automated systems have been doing, that record ends up inside a proprietary database. At which point you are not just using a model. You are living in the ecosystem, and you have lost your own ability to investigate your own history.

The questions to ask before going deep are straightforward. Can our information be exported in a usable form? Which integrations are proprietary? What happens to our workflows if pricing changes? Could a different provider be substituted without rebuilding everything?

Some technology leaders are handling the current uncertainty by refusing long-term AI contracts outright, on the reasoning that it is genuinely hard to know which providers will still be leading in two years. That is a defensible position right now.

Question 15

What should I expect from a first conversation with an AI advisor?

Accepted Answer

Mostly questions about your business, not a presentation about theirs. A good first call spends its time on what prompted the question, what has already been tried, and where you suspect time or money is going. If you are watching slides in the first fifteen minutes, you are in a sales meeting.

The first conversation tells you more about a firm than any case study will, and it costs you half an hour.

Pay attention to the ratio. A useful call is mostly them asking and you talking. If the proportion inverts early, you are being sold a predetermined answer and the discovery is decoration.

Pay attention to what they ask about. Questions about your goals, how the operation actually runs, what your team can absorb, and what governance exists are diagnostic questions. Questions about your budget, your timeline, and who signs are qualification questions. Both eventually get asked. The order tells you what the firm is optimizing for.

Pay attention to whether they will tell you no. The most useful outcome of a first conversation is sometimes that you do not need help right now, or that the thing you need is not the thing they sell. An advisor willing to say that in the first thirty minutes is demonstrating the exact behavior you would want from them six months into an engagement.

Nothing needs to be prepared for a call like this. Useful things to bring, if you have them: what prompted you to look into this now, what has already been tried and what happened, where you suspect the losses are, and what your board or leadership is asking for.

If you want to have that conversation with us, it is at cal.com/team/blanecanada/discoverycall, or 630-492-0582.

Question 16

Should we buy an enterprise AI operating system?

Accepted Answer

Probably not yet, and for most mid-sized companies not at all. The need it addresses is real, because AI is spreading across systems faster than anyone is tracking it. But the market is unsettled enough that committing to one provider now is a bet on which vendor still leads in two years.

The pitch is coherent, which is what makes it persuasive. You have AI running inside six platforms, each added it on its own schedule, nobody has a full view of what is deployed or what it can reach, and here is a layer that sits above all of it and gives you control.

The underlying problem is genuine. That is the sprawl question, and it gets worse rather than better as your existing vendors keep adding AI features you did not ask for.

What gives me pause is the timing. Some serious technology leaders are deliberately refusing long-term AI contracts right now, on the reasoning that it is genuinely hard to know which providers will still be leading in two years. One described the posture as staying dynamically defensive. Buying a control layer is a heavier commitment than buying a tool, because everything downstream ends up shaped by it.

It is also worth knowing what the market has actually settled into, which is a hybrid. Most organizations use provider-native controls for some workflows and something external for others, because they trust no single provider enough to hand over the whole environment and lack the engineering capacity to build it themselves. That is a compromise rather than an answer, and it tells you the category has not matured.

If you do go looking, the piece with the clearest value is observability rather than orchestration: knowing what your systems are doing, what they are reaching, when behavior drifts, and having a forensic record afterward. One technology leader described wanting the equivalent of an application monitoring platform, built for AI. That is a narrower purchase and a much easier one to reverse.

For a company of thirty to three hundred people, my answer is that you do not need to buy this. Know what you have, require that anything touching customer or employee data gets reviewed before it goes live rather than after, keep your own records in a form you can move, and avoid long commitments while the ground is still shifting. Revisit it when the sprawl becomes something a person can no longer hold in their head.