ChatGPT, a ready-made AI service or custom development: how to choose

For an occasional email draft, an AI chat tool is usually enough. An employee describes the situation, reads the response, corrects it and sends the email. A separate application would add little value.

Daily prospect research involves more steps: collecting information, selecting suitable companies and passing contacts to sales. Manual chat may struggle to support that process. Even then, ready-made services can offer scheduling, connections to other systems and automated actions. Those requirements alone do not justify custom development.

I start by tracing the work: where the information comes from, what an employee does with it and where the checked result needs to go. Sometimes a reusable prompt is sufficient. Configuring an existing business system, removing an unnecessary approval or writing ordinary code without AI may also solve the problem. Custom development becomes worth considering when the available tools leave important work unfinished.

Six criteria for comparing your options

Assess the complete task, including preparation and review. A fast answer is less useful if gathering its inputs and correcting its output still take most of the employee's time.

The right-hand column describes requirements, not a verdict in favor of development. First check approved company tools and ready-made services against those requirements.

A connector, meaning a prebuilt connection to another system, may save you from commissioning an integration. Its usefulness depends on the details. A product description saying “CRM integration” does not establish that it can read the fields you need or write the result to the right record.

For each option, mark each requirement as tested and available, available with configuration, or missing. This turns a broad product comparison into a practical decision about what still needs to be bought, configured or built.

Where a prompt leaves work unfinished

Suppose an employee exports accounting records, finds the matching customer in the CRM, copies the information into chat and then transfers the answer back. The model may speed up text processing, while every manual transfer remains. Staff still spend time moving information and can attach an answer to the wrong record or omit part of the input.

The next step is to test whether existing connections can handle those transfers and identify what work would remain afterward.

Advertiser discovery: collecting the right information first

In an advertiser discovery project for an international advertising agency, the sales team had already tried ChatGPT and other large language models, or LLMs. Direct searches produced poor results. Promising advertisers often came to the team's attention after competitors had signed contracts with them.

There was no single directory of companies ready to partner. Useful information was scattered, while established advertisers were already familiar to the market. The agency needed recurring research for a defined category of prospects.

I discussed the process and selection criteria with the head of sales, defined the requirements, built a prototype, and independently developed and launched the system. It collects specialist industry analytics through source APIs and interfaces. An API lets software exchange data without a person copying it between screens.

Custom algorithms process and structure that information, and the system identifies the legal entities behind the businesses. Web search and language models then help find contacts, partnership terms and affiliate programs. Leads that meet the criteria go into a Google Sheets spreadsheet with the details sales needs for an initial approach.

For that prospect category, the team receives a regular prepared selection. It does not provide complete market coverage, guarantee earlier discovery than competitors or turn a lead into a signed deal.

Customer-facing answers need different controls

When a model sends an answer directly to a customer, there is no employee reviewing it first. Confident wording is not evidence that the answer is correct, so a successful sample conversation is insufficient grounds for choosing a product.

A psychologist commissioned a Telegram self-help bot using his method. The client supplied the method. I selected the language model, wrote instructions that account for the conversation context and current task, and built controls that track dialogue state. Those controls help bring the conversation back to the method after a deviation, including one caused by a model error, and manage the priority of issues being discussed.

I also implemented automatic selection of reasoning depth and caching, which reuses stored data to reduce token costs. These conversation controls still need testing and cannot ensure that every answer is correct. A buyer needs to examine how such a product behaves in difficult situations as well as routine conversations.

Bulk document processing needs a different kind of review: required fields, permitted values, consistent records and calculations that add up. Ambiguous cases should go to a person. A wrong category on an internal note and an incorrect customer message have different consequences, so their checks should differ too.

Establish where data may go before testing

Before using work materials in a trial, confirm that the chosen service is permitted to process them. Removing names and company details does not necessarily make a document safe to upload. Other personal data or trade secrets may remain.

Public and enterprise versions of the same product can differ in contract terms, storage, processing settings and administrator controls. Assess the specific service and configuration. An enterprise label does not grant permission to upload every document.

When I led development of an enterprise product at Gazprom Neft, an energy company, corporate security, data-handling and approved-software requirements affected the technical choices. In this situation, it makes sense to start with tools the company has already approved. If they fit the workflow, confidentiality may not require a custom system.

Compare cloud services, enterprise offerings and self-hosted models by their actual processing conditions and access controls. Hosting in a particular country does not, by itself, establish acceptable processing. A model on your own servers does not establish isolation either: the other components and connections must be checked.

The organization responsible for the data should agree on requirements with its legal and information security specialists. The engineer then implements the agreed requirements for data location, deployment and access. Once permitted processing is clear, quality can be tested on representative materials. For document workflows, the article on AI invoice processing explains the checks before data reaches accounting.

Use a one-week trial to find the missing capabilities

If the task is not yet well understood, have an employee who knows the process perform it in the chosen chat tool or ready-made service for a week. Use only data permitted in that tool.

Keep a simple log of inputs, results and interventions. Record what had to be prepared, transferred, corrected, delayed or set aside. Include successful cases so you can judge how often problems occur. If an input cannot be uploaded, record the restriction without uploading the material.

At the end of the week, group the difficulties by cause:

• Repeated transfers between systems. Identify the source and destination, then test available connectors on those exact operations. Any missing operation becomes a specific integration requirement.
• Answers that need correction. Separate format and calculation errors from errors in meaning. Rules can check a date format or a total that does not add up. Ambiguous conclusions need a defined reason for human review and someone to handle it.
• Work that cannot be completed in time. Locate the delay: preparation, manual starting, waiting for the model or checking the output. Scheduling will not fix a review bottleneck.
• Materials the service cannot process under company rules. Look for an approved alternative. If none exists, agree on processing requirements with those responsible for data, legal matters and information security. Do not bypass a restriction to finish the experiment.

Use the log to update your comparison of options. “We need AI automation” can now become a concrete requirement: import these records, check this field or send this type of uncertain result to an employee.

If little intervention was needed, the existing tool may be sufficient. Save effective prompts and examples of output checks so colleagues can repeat the work. The log may also reveal a process change that removes a transfer without adding another service.

A week supplies initial evidence. It does not prove that a solution can handle peak loads or every rare case.

Basic rules still matter when staff use chat

Manual chat needs a simpler operating process than a customer-facing automated service, but access, data use and review still need attention.

Where supported, use company-managed accounts. Establish who grants and revokes access, what happens to work history when someone leaves and which settings administrators can control.

Give employees examples of permitted and prohibited inputs using familiar contracts, emails and exports. A general instruction not to send “confidential information” leaves too much room for interpretation.

Before an answer goes into a report or reaches a customer, someone should be responsible for checking the facts, calculations and suitability for the task. Name the reviewer so everyone knows who will perform that check.

Employee-built software needs technical review

An employee may use AI to write a script that cleans an export or prepares a weekly report. Even if only its author uses it, the script can hold access keys, read company data or change records in business systems. User count alone does not determine the risk.

At a company within a corporate group, employees were creating useful tools with ChatGPT and Claude. Security had not been properly addressed, and there was no process for support, wider deployment or colleague access. An author without development experience could overlook keys in source code, dependence on a personal account or unsafe settings.

I designed and agreed on a release process for these employee-built applications. The author completes the basic preparation covered by the instructions and submits the project with its code in corporate GitLab, the company's code repository. A technical owner, the specialist responsible for the application, reviews the code, makes necessary improvements and assesses technical readiness. A DevOps specialist handles deployment through automated checks into test and production environments.

After launch, the technical owner continues maintaining the application and coordinates with DevOps and administrators. For a manager, the practical requirement is company-accessible code, a named specialist to review and maintain it, and a clear support process. The article on rules for employee-built AI tools explores these responsibilities further.

What custom AI integration actually includes

When available tools cannot meet the requirements, much of the development effort falls before and after the model's response. Understanding that work helps you compare a custom solution with a ready-made service on realistic terms.

Data collection and processing

I first work through the process with employees: the current steps, what makes a result acceptable and which exceptions occur. A trial log gives that discussion concrete examples.

The system then needs to retrieve data and match records about the same entity. A company may have different names in two systems. Rules and a model can work together to match them, with ambiguous matches sent for review.

The collection method also affects cost and maintenance. APIs and scraping, which extracts information from pages, differ in availability, terms of use, completeness and upkeep. Scraping is not necessarily cheaper, and an API may omit information the workflow needs. I explain those differences and their budget implications before a choice is made.

Calculations and unambiguous operations are usually more reliable in conventional code. Language models can help interpret varied information, although free text does not always require an LLM. The decision depends on quality, cost and the consequences of mistakes. The article on choosing between AI and rules gives examples of this division.

Output checks and application features

Data processing needs a defined output structure, validation rules and conditions for human review. Conversations need instructions, context, topic management and an appropriate reasoning depth. Both should be tested with incorrect and ambiguous inputs as well as straightforward ones.

Agreed data requirements determine hosting, permissions and protection of connections. Self-hosting requires computing resources and maintenance; an external service needs assessment of its terms and settings.

Payments, user roles, administration and recordkeeping are also software features that someone must build or configure. They can require more work than connecting the model. In the psychologist's bot, for example, I implemented a trial conversation, the transition to paid use, payment handling and an admin dashboard. Choosing a language model did not address those product requirements.

Handover and ongoing operation

A system used every day needs code in the company repository, documented startup and recovery procedures, and a process for investigating failures and making changes. A named specialist should be responsible for its technical operation after handover.

These tasks make up business automation and AI integration. When comparing development with a ready-made product, include configuration, remaining manual work and maintenance for both options. The missing capabilities and their cost should explain the choice.

Enough information for the next step

Start with one workflow and a few representative examples. Show what comes in and from where, what result is needed and where it should go. Describe an unacceptable error, any known data or access restrictions, and who accepts the result and handles exceptions.

If you have a trial log, specification or process documentation, use it. There is no need to create a detailed specification before an initial discussion, and the one-week trial is a diagnostic option rather than a prerequisite for contacting me.

Send a short workflow description and any examples you are permitted to share for a free initial written exchange. That is enough to begin assessing whether to keep the work in chat, configure or buy an existing capability, or investigate a specific development requirement.