NEW
Trusthref.com: AI Agents That Grow Your Business In Autopilot
NEW
A vendor says “we do AI,” and the meaning behind that phrase is rarely clear. Some teams design and train custom systems from the ground up. Others wrap a single API call from a provider like OpenAI in a branded interface and charge a recurring fee for access. This distinction is not incidental; for a meaningful share of the market, it is the entire business model, and sales materials are often written to keep the difference unclear.
A genuine AI development agency designs the system architecture, trains it on a client's own data, and delivers something that keeps improving with use. That standard is not universal. Plenty of firms license a chatbot platform, apply a client's branding, and present the result as custom work, all while operating under the same label.
Both types of vendors tend to use similar language: “custom AI,” “tailored to your workflow,” “built to scale with your business.” A well-produced deck does not indicate who wrote the underlying code, and neither does a confident presentation.
The distinction becomes visible in the questions each vendor asks. A team capable of real engineering will ask about the client’s data before proposing an outcome: where it is stored, its quality, its format, and whether it can legally leave company servers. A reseller typically moves straight to timeline and pricing, because the underlying tool already exists. In that model, the vendor is selling access rather than engineering, which is a legitimate offering as long as it is represented accurately.
Every AI system produces incorrect output at some point. A confident, well-formatted answer that happens to be wrong is arguably the most difficult failure mode to catch, since nothing about its presentation signals an error. It is worth asking directly what happens when the system generates an incorrect figure in a client-facing report, misroutes a request, or misclassifies a transaction.
A team with genuine technical depth will describe its approach to monitoring, fallback logic, and drift detection. Model drift is a documented phenomenon: a system tuned on last year’s data can degrade gradually, often without anyone noticing until a customer raises the issue. A reseller frequently defers to the underlying provider in these conversations. That response is reasonable once. If it becomes the default answer to every technical question, it is worth noting.
Requesting access to the codebase, or a representative portion of it, is a reasonable step. The purpose is not simply due diligence; it clarifies how much flexibility the client will retain later. A system built as a thin layer over a third-party product offers limited ownership, and licensing costs for that kind of arrangement tend to increase over time.
Firms with genuine engineering capability typically use frameworks such as LangChain to coordinate multi-step reasoning and vector databases such as Pinecone for retrieval, along with custom integration work connecting a language model to a client’s existing systems. Resellers, in comparison, often build on top of platforms such as Zapier and describe the resulting workflow as “AI-powered.” That approach can perform adequately for a narrow task, but it tends not to hold up as requirements become more complex, and that limitation is not always disclosed during the sales process.
Pricing structure is often a reliable indicator. A reseller’s costs typically scale with seats, messages, or API calls, since the vendor is applying a markup to a third party’s usage-based pricing. A development partner’s costs typically scale with engineering hours, reflecting the ongoing work required to build and maintain a system specific to the client.
Neither pricing model is inherently disadvantageous. Reselling an established tool can be the right choice for a team that needs a working solution quickly. The issue arises when a client pays custom-development rates for what functions as a subscription with minor customization. It is worth reviewing the contract closely: if “customization” amounts to a revised color scheme and a modified welcome message, that is a rebranding exercise rather than custom development.
Asking a vendor to describe, in real time, how it would address a specific edge case in a client’s workflow is an effective evaluation method. Examples include a query outside the system’s training data, a document in an unexpected format, or a request submitted in a less common language.
A team with direct implementation experience will typically ask clarifying questions, outline a rough approach, and acknowledge areas of uncertainty. That hesitation is a reasonable indicator of genuine engagement, since immediate certainty about an untested scenario is often unwarranted. A reseller tends to respond quickly and in general terms, reflecting limited familiarity with the system’s internal logic.
Launch tends to receive the most attention, but the months that follow reveal more about a vendor’s capability. Providers update underlying models without notice, usage patterns shift, and a system that performed well during testing can decline in accuracy as data volume grows or user behavior changes.
It is worth clarifying who is responsible for that ongoing performance once the initial engagement concludes. A firm with real development expertise will typically describe a plan for retraining, evaluation, and early detection of quality issues. A reseller’s maintenance offering is often limited to a support queue for a tool it did not build, which addresses basic issues but is less effective when core logic degrades.
For a retail business running a product-recommendation feature, an occasional incorrect output carries limited consequence. For a healthcare intake system or a financial services application handling client data, the same error can create regulatory exposure. In these contexts, the distinction between a builder and a reseller shifts from a budget consideration to a compliance one.
It is reasonable to ask directly about data residency, the availability of private or on-premises deployment, and whether sensitive information passes through a third-party model provider’s infrastructure. A team with genuine infrastructure experience will typically have a clear answer prepared. A reseller operating a general-purpose chatbot platform often cannot offer that level of control, since the underlying architecture was not designed with it in mind.
Case studies are produced by the vendor, for the vendor’s benefit. A conversation with an actual client is a more reliable source. Requesting two or three references, ideally clients who have used the system for a year or longer rather than a recent launch, provides a clearer picture.
Useful questions for a reference include response time when issues arise, whether costs remained close to the original estimate, and whether the client would engage the same vendor for a future project. Review platforms such as Clutch and G2 offer an initial signal, though a direct conversation typically provides more reliable information than aggregated ratings.
Several patterns tend to recur among vendors positioned as developers but functioning primarily as resellers. No single indicator is disqualifying, but two or more occurring together warrant further scrutiny.
Technical questions are consistently redirected to a feature list
The vendor cannot clearly explain data handling once information leaves the client’s systems
Pricing is structured entirely around seats or message volume, with no reference to engineering time
No one on the call can speak to model evaluation, testing, or drift monitoring
The proposed timeline appears disproportionately short given the stated scope
The definition of “custom” shifts each time the client asks for specifics
None of these patterns indicate dishonesty on their own. A lighter, off-the-shelf solution is sometimes the appropriate choice, and a credible reseller will state that plainly rather than presenting it as bespoke engineering. Concerns arise when pricing and messaging promise custom development that does not materialize.
Identifying a genuine development partner depends less on the length of a proposal and more on a short set of direct, specific questions asked early in the process: who wrote the code, how the system handles errors, and where the engineering budget is actually allocated. These questions are best asked before a contract is signed, not after implementation is complete.
AI tools to find & convert leads. 
Send emails at scale
