DEV Community: Silvia

Off-the-Shelf or Custom Software: How to Decide

Silvia — Sat, 31 Oct 2026 01:36:42 +0000

When a business needs software to run part of its operations, such as scheduling work or handling quotes and orders, the choice usually comes down to buying an existing product, building one, or combining the two.

Existing products are usually the right place to start looking, since they show what the market already handles and where any custom work would need to focus. For work most businesses handle the same way, a product someone else builds and maintains is often faster to adopt and less expensive up front than building your own.

The decision rarely depends on whether a business is "unique." It depends on how well the available products fit the way the work is actually done, whether their gaps are worth connecting or building around, and what each option costs over time.

1. What Does the Workflow Actually Require?

Before comparing products or estimating a custom build, identify each step of the work as it is done today. This is not the process described in a policy document. It is what happens when a real order, project, or service request comes into the business, step by step.

It helps to include both the people who do the work and the people who track its cost. The first group knows where the workarounds are. The second can estimate what they cost.

Questions to consider include:

What are the main workflows the software will be part of, from start to finish?
Which steps are handled today in spreadsheets, email, paper, or someone's memory?
Where is information entered more than once?
Which steps depend on one or two people who know how to get them done?

Not every step should carry over. Some exist only to work around the tools in use today, such as copying data between spreadsheets or checking totals by hand. These are usually better removed than carried over.

If the process is new or still changing, note that too. Custom software built around it will likely need changes until the process settles.

2. How Well Do the Available Products Fit?

With those steps identified, group them by how much a gap in each step would affect the business:

High impact: steps that bring in revenue, affect what customers receive, or carry compliance or financial risk.
Medium impact: steps the business relies on regularly, where a gap would cost significant staff time, with limited direct impact on revenue or customers.
Low impact: occasional or minor steps, where a gap would be an inconvenience.

Then compare each step against the products you are considering, and mark whether each product:

Handles it: the step is done fully in the software.
Partly handles it: the software does some of the step, and people fill in the rest.
Does not handle it: the step is done entirely outside the software.

Keep in mind that a vendor demo follows the vendor's script. During a trial, run a few real, recent jobs through the product, including one that was difficult to handle, and note where people have to leave the software to finish the work.

Look closely at the steps marked as partly handled. They are easy to treat as close enough, but that is usually where the spreadsheets, copied data, and manual checks end up.

Start with the high-impact steps. A gap there weighs much more than a gap anywhere else. A product that misses a minor reporting step is in a very different position from one that misses part of how the business quotes, prices, or schedules its work.

Check Whether the Software Enforces the Process or Only Allows It

A product can have every feature the business needs and still leave room for costly mistakes.

There is a difference between software that allows a process and software that enforces it. A quoting tool may let a salesperson add any item to a quote, but it may not check that a quote for a certain type of job includes everything that type of job requires. The feature is there. The safeguard is not.

Example. A company that installs equipment uses a quoting product that covers every feature on its list. But nothing stops a salesperson from leaving out the mounting hardware or cabling a job requires. The missing items are discovered after the contract is signed, and the company absorbs the cost on job after job.

For each high-impact step, ask both questions: can the software do this step, and does it catch predictable mistakes before they become costly? A product that covers the features but not the safeguards may fit less well than a feature checklist suggests.

Check the Requirements That Apply to the Whole System

Beyond the individual steps, check the requirements that apply to the whole system: who can see and change what, how data is backed up and restored, how much downtime the business can tolerate, and any rules about how customer or financial data is stored and handled. A product that fits every step can still be ruled out by one of these, and a custom build has to meet them too.

As a rough guide, if a product handles most of the workflow as it is, and the steps it misses are low or medium impact rather than high, buying is a strong candidate, provided the remaining gaps are inexpensive to manage. When they are not, or the gaps fall in high-impact steps, the next question is what it would take to close them.

3. What Would the Business Need to Add or Build?

The choice is not always between buying a product and building everything. Each gap that matters can usually be handled in one of four ways:

Buy as-is. Use the product as it comes and adjust the process around the gaps. This works when the gaps are minor, or when the step is better changed than supported.
Configure or connect. Close the gap with more configuration, an add-on, or an integration that moves data between two systems so it does not have to be entered twice. AI-based automation can now handle some of the work around steps a product only partly handles, such as flagging records that do not match. These automations still need someone to check their results and keep them working when either product changes.
Build a focused tool. A small custom tool that handles one step the product does not support, such as a quote calculator, an approval workflow, a customer portal, or a dashboard. Tools like this were often hard to justify; AI coding tools have lowered the cost of building one.
Build a larger system. Custom software for a team's main daily work. This fits best where the workflow is well understood, not heavily regulated, and poorly served by the available products, and where someone can own the result. A working prototype can test whether a custom approach fits before the business commits to it.

Combining a product with a focused build keeps the vendor responsible for the parts of the workflow that are standard, while the business owns only the part that is specific to it. It is often less expensive than a full custom build and less disruptive to the people using the software every day.

When Buying Is the Stronger Choice

Good fit. A reasonably priced product already fits the workflow, and its remaining gaps are inexpensive to manage.
Changing rules. Tax rules, reporting requirements, or regulations change constantly, and established products absorb that work for every customer at once. Accounting and payroll are the clearest examples. A custom system would have to keep up with those changes on its own.
Standard functions. The function works the same way for nearly every business, such as email, document storage, and basic scheduling or invoicing for businesses that operate the way most others in their industry do. These are rarely worth building, even when the product is not a perfect fit.
Shared maintenance. Beyond the software itself, the vendor keeps integrations with other systems working, handles unusual cases the business has not run into yet, and provides support the business would otherwise have to arrange.

Confirm what the vendor handles for the specific product during the trial rather than assuming it, since not every vendor delivers all of it. Where the product falls short in these cases, the gaps are usually better handled by adjusting the process or connecting the product to other systems than by building.

When Building Is the Stronger Choice

Competitive advantage. The way the business works is part of why customers choose it, and available products cannot support that approach.
Safeguards. Custom software can enforce the business's own rules, as in the quoting example above, so predictable mistakes are caught before they cost money.
Control. The business sets its own priorities for new features instead of waiting on a vendor's roadmap, though security updates and changes to the third-party services it relies on still arrive on someone else's schedule.
Consolidation. One system built around the workflow can replace several products and the integrations between them, with fewer subscriptions and fewer places for data to fall out of sync.

Example. A home services company wins much of its work by sending quotes within the hour, priced from its own job history. The products it evaluates use a fixed price book and a manager approval step. Adopting one would mean slower, less tailored quotes. That cost would show up as lost jobs, not as a line on any invoice.

4. What Does Each Option Cost Over Several Years?

A fair comparison counts the up-front and ongoing costs of every option still being considered, over the same period.

Off-the-Shelf Software

The cost of off-the-shelf software is not limited to the license fee. It usually shows up in four places, and only one of them is labeled as software. Some of these costs are visible in the vendor's pricing or proposal. Others become clear only when people use the product.

Higher tiers or extra seats. Pricing is often per user or per feature tier, and a feature the workflow depends on may only be available in a more expensive tier, or may require a license for everyone who needs it. Many vendors also sell AI features as a separate add-on, often charged per user, or only in higher tiers. Annual price increases add up over the length of the contract.
Configuration and customization. Consultants, implementation partners, or internal staff may be needed to adapt the product to the business. This cost usually appears as services rather than software, so it is rarely compared against the license fee.
Workarounds. Spreadsheets, repeated data entry, manual reconciliation between systems, and fragile automations that connect them. This cost appears as staff time and errors rather than as a software expense.
Vendor changes. The vendor decides when features change, move to a higher tier, or are retired. Each change can mean updating configuration, integrations, and training. Products can also be acquired or discontinued.

Example. A service company chooses a scheduling product that does not handle the way it prices recurring work. Every week, an office manager exports the schedule, applies the pricing in a spreadsheet, and enters the totals into the accounting system. No single step looks expensive, but over a year it adds up to weeks of staff time, plus the cost of every pricing error that reaches a customer.

To estimate the workarounds, take the hours per week each gap would require, multiply by the cost of the people doing the work, and project it across several years. For example, a gap that takes five hours a week, at a staff cost of $40 an hour including taxes and benefits, adds up to $10,400 a year, before any errors or rework. Keep in mind that time saved gives staff room for other work. It does not necessarily reduce payroll, so treat it as added capacity unless the business actually plans to reduce hours.

Custom Software

For custom software, the cost includes both the initial build and ongoing operation. Hosting, security updates, upgrades to the tools it is built with, fixes, and changes as the business grows continue for as long as it runs, and they belong in the comparison.

AI coding tools have lowered the cost of building. Screens, forms, data access, and the code that connects systems can now be written in much less time than a few years ago. The rest of the cost has not dropped as much. Understanding the real process, its exceptions, and its rules still takes time with the people who do the work. Tools can help write and run tests and flag common security issues, but someone still has to decide what needs to be tested and whether the results are good enough. Software that nobody fully understands becomes harder to change later.

Costs Both Options Carry

Both options also carry costs that are easy to leave out: moving existing data into the new system, training the people who will use it, the disruption while it is rolled out, and ongoing support when something goes wrong. These can be significant either way.

With per-user pricing, license fees rise as the team grows. Custom software avoids those seat fees, but it can still carry license and usage charges for the third-party services it is built on, and its hosting and support costs can grow as more people use it. When those costs grow more slowly than the license fees would, the case for building gets stronger as the team grows.

Consider Who Owns the Software and the Data

Ownership affects what it would cost to change course later. Both options carry a form of lock-in, and neither is automatically the smaller commitment.

For off-the-shelf software, a product used mostly as it comes can be easy to replace if it stops fitting, but the more business logic is built into it through configuration, the more expensive it becomes to move away from it. Confirm that the business can export its data in a usable format if it ever needs to leave.

For custom software, a focused tool can be inexpensive to revise or retire, but a larger system can be costly to change. Confirm that the business owns the code, has access to where it is stored, and has enough documentation that another developer could take it over. Custom software that only one person or one vendor understands is its own kind of lock-in.

5. Which Option Can the Business Support Now?

Even when custom software is the better long-term choice, it may not be the right choice yet.

Estimate how long it would take custom software to pay for itself compared with the best viable alternative, which may include keeping the current process. Divide the extra up-front cost by what custom software gains each year over that alternative: its added benefits, adjusted for any difference in ongoing costs. If that yearly gain is zero or negative, custom software does not pay for itself on these numbers. If the business cannot fund it now, or the payback is too far away, starting with off-the-shelf software and accepting the workarounds may be the better decision for now.

Decide, too, who will be responsible for the software once it is in use, whether that is someone on staff or an outside developer. If no one can take that on yet, a product the vendor maintains is the safer choice for now.

Custom software also does not have to mean building everything at once. Start with one gap that is costly enough to matter but contained enough to build and evaluate on its own, with benefits that can be measured, such as hours saved or errors avoided. In the meantime, the rest of the workflow can continue as it is done today, or run on an off-the-shelf product.

Once the first piece is in use and the results are clear, decide whether the rest of the workflow can be handled by an off-the-shelf product or needs more custom software. Building in stages limits how much is committed before the approach has proven its value.

Whichever path the business takes, the answer can change as it grows. Repeating this review once a year makes it easier to recognize when the balance has shifted: the workarounds now cost enough to justify building, or a product has caught up with something the business built.

Choosing Software Does Not Have to Be All or Nothing

Start with how the work is actually done, find the gaps that matter, and compare the full cost of each way to close them, including the costs that never appear on a software invoice. For many businesses, the answer will be an off-the-shelf product. For others, it will be a product connected to other systems, a focused tool for one gap, or a larger build. The goal is software that fits how the business works, at a cost the business can sustain.

Using AI With Private Business Data

Silvia — Sat, 31 Oct 2026 01:23:31 +0000

One of the first questions that comes up when an organization considers using AI is what happens to its data.

An AI feature may need information from customer records, internal documents, financial systems, support history, or other business data to provide a useful answer. That raises reasonable questions about what information leaves the organization, where it is processed, how long it is retained, and who can access it.

Using AI with business data does not necessarily mean giving an AI provider direct access to internal systems or sending large amounts of information outside the organization. How the application is designed determines what the AI can see and where different parts of the processing take place.

The following sections cover how to limit what the AI receives, where the AI model should run, how to protect access to the data, and how to choose an approach based on the data involved.

1. Send Only the Data the AI Needs

The simplest approach is for an existing application to send selected information to an AI provider to perform a specific task.

The AI provider does not need direct access to the systems where the data is stored. The application remains responsible for deciding what information is retrieved and sent. That makes it possible to minimize the data sent to the AI.

For example, an application might use AI to summarize a customer case. The application retrieves the relevant case notes from its own database, sends those notes to the AI provider, receives the summary, and displays it to the user. The AI needs the details of the case but may not need the customer's name, account number, or contact information. Those details can be left out, or replaced with a placeholder such as "Customer A" before the request is sent.

This reduces how much information is sent and how much of it identifies a customer. However, the information that is sent is still processed by the AI provider, so the provider's terms need to be reviewed before sensitive information is included (see section 5).

2. Retrieve Relevant Information Instead of Sending Everything

Some applications need to answer questions using a large collection of internal information, such as policies, contracts, procedures, or product documentation. In these cases, the application cannot simply retrieve the information it needs. It first has to find which documents are relevant to the question.

A common approach is retrieval-augmented generation, usually called RAG. Instead of sending all of this information to an AI provider, the application searches the organization's information for content related to the user's question. Only the relevant information is then sent to the AI provider.

For example, if an employee asks:

"What is our policy for reimbursing international travel?"

The application might find the relevant sections of the company's travel policy and send only those sections to the AI provider.

This reduces the amount of information sent for each request. However, the selected information is still processed by the AI provider. RAG limits what is sent; it does not prevent the selected information from leaving the organization's environment.

3. Keep Calculations Inside the Application

Some questions can be answered without sending the underlying records to the AI provider.

Consider a user asking:

"How much did Customer A spend last quarter?"

One approach would be to retrieve every transaction for that customer and send the transactions to an AI provider to calculate the total. That sends more information than necessary and uses AI for a calculation the database can perform directly and reliably.

A better approach is for the application to calculate the total itself. If an AI model is used to phrase the answer, it receives only the result, not the individual transactions behind it.

The same principle applies to account balances, pricing calculations, inventory levels, financial totals, eligibility rules, and other information that existing systems can determine reliably. AI does not need to perform every step simply because the application includes AI functionality.

This reduces what is sent, but it does not remove the AI provider from the picture. The user's question itself, including the customer's name, is still sent, along with the application's result, which the AI uses to write its answer.

4. Let AI Interpret the Request Without Seeing the Results

In some cases, the AI model does not need to see the business data at all.

Suppose a manager asks:

"Show me customers with invoices more than 60 days overdue."

The AI model does not need access to the customer records to understand what the user wants. It can translate the request into simple search criteria that the application already knows how to handle, such as:

Invoice status: unpaid
Days overdue: greater than 60

The existing application then checks the user's permissions, validates the criteria, runs a search it already supports, and displays the results.

With this approach, the AI model helps interpret the user's request, but the resulting customer records are never sent to the AI provider. This can be useful when an organization wants a conversational interface without sending that business data to an outside provider.

It also creates an important security boundary. The AI model is not given open-ended database access. It can request only operations that the application explicitly supports.

The tradeoff is flexibility. The application can answer only the kinds of questions someone has built support for in advance, so each new type of request is additional development work. The user's question is also still sent to the AI provider.

5. Decide Where the AI Model Should Run

Another important decision is where the AI processing takes place.

Use a Business or Enterprise AI Service

Major AI providers offer business services with additional controls over how submitted data is secured, accessed, retained, and used. These services are available directly from AI providers and through cloud platforms such as Microsoft Azure and AWS.

Business terms differ from the consumer versions of the same products. A free or personal account may handle data very differently from a business account with the same provider, so it is worth confirming which version is actually being used.

When evaluating a service, organizations should understand what data is retained and for how long, whether submitted data may be used for model training, and what security and access controls are available.

Using a business AI service does not remove the need for good application design. Organizations should still determine what information the AI actually needs and avoid sending unnecessary data.

Run the Model in a Private Environment

For organizations with stricter data requirements, another option is to run an AI model within an environment they control.

For example, an organization could run an open-weight model, meaning an AI model that anyone can download and run, rather than one that is available only as an online service. It could run on the organization's own servers or within a private cloud environment instead of sending requests to an outside AI provider. This gives the organization greater control over where its data is processed.

The tradeoff is that the organization takes on more responsibility for running and maintaining the model, including security, updates, monitoring, performance, and the servers it runs on. A model run privately may also be less capable or slower than those offered by the major AI providers.

For some organizations, the additional control may justify the added complexity. For others, a business AI service with appropriate security and data controls may be more practical.

6. Protect Access to the Data

Where the model runs is only one part of protecting business information. An AI feature can introduce security risks even when the AI provider has strong data protections.

Consider an internal AI feature that can search documents across the company. If an employee normally has access only to sales data, the application should not allow that employee to use the AI to access HR files, executive documents, or financial records they are not authorized to see.

The application should verify who is making the request and what information that person is allowed to access. It should also limit what information and systems the AI feature itself can access and avoid exposing sensitive data unnecessarily.

The same principle applies to any records the application keeps. If it saves questions and AI responses, those records contain sensitive information too and need the same protection as the original data.

Adding AI should not give users access to information they would not otherwise be authorized to see.

7. Choose the Approach Based on the Data

There is no single approach that is appropriate for every AI application. A system that works with public product information has very different requirements from one that works with customer financial data.

Questions to consider include:

What information does the AI actually need?
Is any of that information confidential, personal, financial, regulated, or contractually restricted?
Does the AI need the underlying records, or can the existing application perform the sensitive operation?
Can identifying information be removed?
Where is the information allowed to be processed?
How long may it be retained?
Who should be able to retrieve it?
What happens if the AI requests information the user is not authorized to access?

Those answers can lead to very different implementations, and several of the approaches above are often combined in a single application.

Using AI Does Not Have to Mean Giving Up Control of Your Data

The question "Can we use AI with our private data?" does not have a single yes-or-no answer.

In many cases, existing applications and databases should continue handling the business rules, calculations, and sensitive operations they already perform well, while AI is introduced only where it provides a specific capability.

That might mean sending a carefully selected piece of information to a business AI service, retrieving only a few relevant sections of internal documentation, using AI to interpret a request without exposing the results, or running a model in a private environment.

The right approach depends on the sensitivity of the data, the business requirements, and how much control the organization needs over where information is processed.

Sensitive data does not automatically rule out using AI. The goal is to give the AI only what it needs, in a place the business is comfortable with, while maintaining its security and privacy requirements.

Adding AI to an Existing Application Without Rebuilding It

Silvia — Sat, 31 Oct 2026 01:19:08 +0000

Most organizations exploring AI already have an application that works. It supports daily operations, holds years of business data, and is familiar to the people who use it. The question is rarely whether to replace that application. It is whether AI can make it more useful without disrupting what already runs.

There is a common assumption that adding AI requires a new platform, a new architecture, or a rebuild of the existing system. In most cases it does not.

For the majority of business use cases, AI is added the same way other capabilities have always been added: as a new feature that uses an external service. Your application continues to do what it does today, and one part of it gains the ability to summarize, classify, draft, extract, or answer questions. A focused first implementation is often measured in weeks rather than quarters, and it can be limited to a single workflow while the rest of the application remains untouched.

The following sections outline one way to approach that work.

1. Start With a Problem, Not With AI

The most common reason AI projects fail is that they begin with the technology rather than with a specific problem.

A useful starting point is a task that people in your organization perform repeatedly, that involves reading or writing text, and that consumes meaningful time without requiring deep judgment on every instance.

Examples include:

Summarizing long documents, reports, or case notes so that staff can review them faster
Categorizing incoming requests, tickets, or emails so they reach the right team
Extracting structured information from documents such as invoices, contracts, or forms
Drafting a first version of routine correspondence that a person then reviews
Answering questions about internal documentation or policies

Questions worth asking before committing to anything:

How much time does this task consume each week, and who performs it?
What happens today when the task is done slowly or inconsistently?
Would a good first draft or a suggested answer be valuable, or does the task require a guaranteed correct result every time?

If you cannot describe the problem and the expected benefit in a few sentences, the project is not ready to start.

2. Understand What AI Is Suited For

Modern AI services are strong at working with language and unstructured content. They are well suited to summarizing, rewriting, classifying, extracting information, and answering questions about material they are given.

They are not a replacement for your existing business logic. Calculations, pricing rules, account balances, compliance determinations, and anything requiring an exact and repeatable result should remain in your application where they can be tested and audited.

It is also important to understand that AI services are probabilistic. Given the same input twice, the response may differ slightly, and the service can produce answers that sound confident but are incorrect. This is a design consideration rather than a reason to avoid AI. It means the feature should be designed so that an occasional wrong answer is visible and correctable rather than silently acted upon.

Example 1. Consider an AI feature that reads the total from a scanned invoice. Occasionally it misreads a figure. On one invoice, it reads $12,400 as $124,000. If that amount goes straight into the payment queue, the error is difficult to catch. A wrong number looks exactly like a correct one, and nobody has the original invoice in front of them. The error becomes visible with a small change in design. Show the extracted amount directly above the scanned image on the approval screen. The clerk reads one figure against the other and sees a digit that is not on the page.

Example 2. Now consider a feature that assigns a priority to incoming support tickets. It marks an outage report as low priority, and because the priority is applied automatically, the ticket moves into the backlog without anyone reading it. This becomes visible if the agent needs to confirm the priority before the ticket is filed. The agent catches the error because "Low" is now sitting next to a subject line saying the system is down.

Changing the design does not make the AI more accurate, only the mistake easier to catch. In practice, this usually means placing AI where a person reviews the result, or where the output is a suggestion rather than a final decision.

3. Recognize That This Is an Integration, Not a Rebuild

From an engineering perspective, adding AI to an existing application usually means adding a call to an external AI service, in much the same way an application already calls a payment processor, an email provider, or a mapping service.

The application sends the relevant information to the service, receives a response, and presents or stores the result. In most cases the existing screens, database, business rules, and deployment process remain in place.

This has several advantages:

The change can be contained to one workflow or one screen rather than affecting the whole system.
The rest of the application does not need to be upgraded first.
The feature can be released to a small group of users before it is made available more broadly.
If the feature does not deliver value, it can be removed without unwinding a larger project.

Older applications sometimes need a small amount of preparatory work, such as separating the part of the code the feature will touch, or making the required data easier to retrieve. That is typically a focused effort rather than a modernization program.

4. Decide What Information the AI Will Receive

This is the part of the project that most often requires attention from outside the engineering team.

An AI feature is only as useful as the information it is given. This does not mean giving an AI service access to your database. The application remains the intermediary. It retrieves the information relevant to the task at hand and sends only that, one request at a time. A feature that summarizes a customer record sends that record, not the customer table.

If the goal is to answer questions about internal policies, the service needs access to those policies.

That makes the following worth deciding early:

What specific information will be sent to the AI service, and what will deliberately not be sent
Whether that information includes personal, customer, financial, or otherwise confidential data
What the AI vendor's terms state about how submitted data is retained and whether it is used for training
Whether contractual, regulatory, or client obligations restrict where that data may be processed
Who inside the organization needs to approve the arrangement

A common and effective approach is to send only the minimum information required for the task, and to remove or mask identifying details that the feature does not actually need.

The major providers, including OpenAI, Anthropic, and Google, along with the equivalent services offered through Microsoft Azure and AWS, publish business and enterprise terms that address data retention and training use. These terms differ from the consumer versions of the same products, so the question worth asking is which tier your application will actually use.

Resolving this early avoids the situation where a working feature cannot be deployed because the data question was never settled. The options for limiting what the AI receives are covered in more detail in Using AI With Private Business Data.

5. Begin With a Proof of Concept

Rather than committing to a full feature, build a small prototype that tests one question: does this actually work well enough to be useful?

A proof of concept should be deliberately narrow. It typically uses a limited set of real examples, focuses on a single task, and may not include polished screens or full integration with the application. Its purpose is to produce evidence.

Before the prototype begins, agree on what a successful result looks like. That might be a percentage of documents summarized accurately, a percentage of requests routed to the correct team, or a measured reduction in the time required to complete a task. Vague criteria produce inconclusive results.

A proof of concept produces one of three useful outcomes:

The approach works and is worth building properly
The approach shows promise but needs a different design, different information, or a narrower scope
The approach does not work well enough to justify further investment

All three are useful, including the last. It is better to learn that after a short effort than after a long one.

6. Decide What Happens When It Fails

A prototype only has to work. A feature in daily use also has to behave sensibly when something goes wrong, and each of those cases needs an answer decided in advance.

AI requests are typically slower than normal application operations and may occasionally fail or be unavailable. Decide how the feature should behave when that happens. Showing the screen without the AI output, so the user can proceed manually, is usually better than leaving the user waiting or presenting an error they cannot act on.

Users will find wrong answers, and correcting one should be easy rather than merely possible. If fixing a wrong answer takes more effort than doing the task manually, users will stop using the feature and the organization will not learn why.

Running the same request again may produce a different answer. Without a log there is no way to reconstruct what happened when someone reports a strange result. Log only what is necessary to troubleshoot and monitor the feature.

These are the details that separate a demonstration from a feature people can rely on.

7. Plan for Ongoing Cost and Maintenance

AI services are generally billed based on the amount of text processed. Costs are modest for most business workflows, but they are ongoing rather than one time, and they scale with usage. It is worth estimating the expected volume before launch and monitoring actual usage afterward.

There is also a maintenance consideration. AI providers update and retire models over time, which can change how a feature behaves. Treating the AI service as a dependency that requires periodic review, in the same way other third-party services are reviewed, avoids surprises.

8. Measure Whether It Worked

After the feature is in use, compare the results against the criteria agreed at the start.

Useful measures include the time required to complete the task before and after, how often users accept the AI output without changes, how often they correct or reject it, and whether the feature is actually being used. If adoption is low, the reason is often that the feature was placed in a workflow where it did not fit rather than that the technology failed.

This evidence is also what justifies the next step, whether that is expanding the feature to more users, applying the same approach to a second workflow, or stopping.

Adding AI Does Not Require Starting Over

An application that has served the business well for years does not need to be replaced in order to benefit from AI.

The more effective path is usually narrow and incremental. Identify one task where AI is genuinely suited to the work, decide what information the service may receive, build a small proof of concept to test whether it is useful, and integrate it into the existing application in a way that keeps people in control of the result.

The goal is not to add AI to the application. It is to make a specific part of the business faster, more consistent, or less manual, while keeping the system you already depend on stable.

Finding Where AI Fits in Your Business

Silvia — Sat, 31 Oct 2026 01:15:06 +0000

Many conversations about AI start with a tool. Someone has tried a chatbot, seen a demo, or heard that a competitor is using AI, and the question becomes where the business could use it too.

That question tends to produce long lists of ideas and few results. A more useful starting point is the work itself: where it slows down, where it piles up, and where mistakes keep happening.

Some of those problems are a good fit for AI, especially work that involves reading, sorting, or interpreting information that arrives in many different forms. Others are better solved with a simple rule, an integration between two systems, an automated workflow, or a change to the process. Telling them apart before choosing a tool puts the effort where AI makes a real difference.

The following sections outline one way to find where AI fits, rule out where it does not, and choose a first task worth testing.

1. Look Where People Connect the Systems

In most businesses, the slowest and most error-prone work happens between systems rather than inside them. Information arrives by email, sits in a PDF or spreadsheet, and has to be read, interpreted, and entered somewhere else by a person. That person is doing the work of a connection that does not exist.

Common signs include:

Staff copying information from emails, attachments, or forms into another system
Someone reading through long documents to find a few relevant details
Incoming requests sorted and forwarded by hand before anyone can act on them
Reports assembled every week from several sources that do not talk to each other

These tasks are often so familiar that nobody questions them. They are simply how the work gets done.

Questions to consider include:

Where does work wait in a queue before someone can act on it?
Which tasks would stop or slow down if one particular person were out for a week?
Where are the same details typed into more than one system?
Which tasks grow in direct proportion to the number of customers, orders, or requests?
Where do mistakes most often come from, and how are they discovered?

It helps to ask the people who do the work rather than only the people who manage it. They know where the workarounds are and how long they actually take.

2. Recognize the Tasks AI Is Suited For

Good candidates for AI are often tasks like sorting emails, pulling details from documents, matching records across systems, or drafting documents from existing material. They tend to share a few characteristics:

A person can check the result. This matters most for a first project. AI services can sound confident and still be wrong, so start where a person reviews each suggestion before it is used. Later, the level of review can match what a mistake would cost.
They involve reading or writing. The work centers on emails, documents, forms, notes, or other text rather than on calculations.
They happen in volume. The task repeats often enough that saving a few minutes each time adds up.
The input varies. The same kind of information arrives in different formats, wording, or layouts, which makes fixed rules hard to write.
Each instance needs a little interpretation. Someone has to understand what the content means, but not apply deep expertise or make a high-stakes judgment every time.

Example. A property management company receives maintenance requests from tenants by email and through a web form. Tenants describe the problem in their own words: "water under the sink" or "something is leaking in the cabinet." A coordinator reads each one, decides whether it is plumbing, electrical, or general repair, judges how urgent it is, and assigns it to the right vendor. The requests are frequent, the wording varies, and each one needs a small amount of interpretation. AI can suggest the category and urgency, and the coordinator confirms or adjusts it. The coordinator still makes the decision, but no longer has to start from a blank screen on every request.

3. Rule Out the Poor Fits

AI is probably not the right starting point when:

The problem is not defined. If no one can describe what is slow, wrong, or costly, there is nothing specific for AI to improve.
The task is rare. A task done a few times a year rarely justifies the effort to build and maintain an AI feature for it.
The information does not exist. If the knowledge needed for the task has never been written down or recorded anywhere, AI has nothing to work from.
The result must be exact every time. Pricing, account balances, tax calculations, and compliance determinations belong in software that produces the same answer every time and can be tested and audited.
The value is small. If the task takes a few minutes a week, even a perfect solution will not repay the effort.
The main reason is pressure to use AI. Adopting AI because competitors are doing it, without a specific problem in mind, usually produces a feature nobody uses.

Ruling out a task is a useful result. It narrows the list to the opportunities that are worth the effort, and it often surfaces simpler fixes that can be made right away.

4. Check Whether Something Simpler Would Work

Before deciding a task needs AI, check whether a simpler fix would solve it. A simpler fix is usually cheaper to build, more predictable, and easier to maintain.

A rule. If the task follows the same logic every time, such as routing every request from a certain customer to a certain team, a fixed rule in the existing system will be faster and more reliable than AI.
An integration. If the same information is typed into two systems, connecting the systems so the data moves automatically removes the task entirely.
A simple automation. If a task is the same sequence of steps every time, such as sending a reminder two days before each appointment or building the same weekly report, a scheduled workflow can run it without anyone touching it.
A better form. If staff spend time interpreting free-text requests, a form with the right fields may collect the information in a structured way from the start.
A process change. Some steps exist only to work around an old limitation and can be removed rather than automated.

None of these require AI. Some are ordinary automation, and some need no new software at all.

Example. An office manager copies every new order from the online store into the accounting system. The orders already arrive as structured data, with the same fields every time. Nothing about the task requires interpretation. This is an integration problem, not an AI problem, and connecting the two systems would remove the work rather than speed it up.

Compare that with a distributor that receives price updates from dozens of suppliers, each in its own spreadsheet layout with its own column names and product codes. Someone has to work out which column is which and match each product to the distributor's catalog. The inconsistency is the problem, and that is where AI can help, with a person reviewing the matches before the prices are updated.

The two tasks look similar from a distance. Both involve copying information from one place to another. The difference is whether the work requires interpretation.

5. Describe the Opportunity Before Choosing a Tool

Once a task looks like a good candidate, describe it clearly before comparing AI products or vendors. A short written description makes it easier to judge whether the opportunity is real and to explain it to the people who will approve it.

The description should cover:

The task: what is done today, step by step, and what is slow or error-prone about it
The people: who does the work, who depends on the result, and who would review the AI's output
The information: what the task reads, where that information is stored, and whether it includes customer, financial, or otherwise confidential data
The systems: which applications the task touches and where the result needs to end up
The review point: where a person checks the result before it is acted on
The measure of success: how anyone will know it worked, such as time saved, fewer errors, or faster responses

If any of these cannot be filled in, the opportunity is not ready yet. The information is especially worth settling early, since whether it includes confidential data often determines which AI services and setups can be used.

6. Estimate What It Is Worth

A rough estimate of value helps compare opportunities against each other and against the cost of building them.

Start with the time the task takes today. Multiply the hours per week by the cost of the people doing the work, and project it across a year. For example, a task that takes eight hours a week, at a staff cost of $35 an hour including taxes and benefits, adds up to about $14,560 a year.

AI rarely removes a task entirely, especially when a person still reviews the result. A more realistic estimate assumes part of the time is saved. If the AI suggestion cuts the time in half, the value in this example is closer to $7,280 a year.

Time is not the only measure. Some opportunities are worth more for what they prevent or enable:

Errors that currently reach customers or cost money to fix
Requests that wait too long and cost the business work
Growth that would otherwise require hiring someone just to keep up with the volume
Work that stops when one experienced person is unavailable

Keep in mind that time saved gives staff room for other work. It does not necessarily reduce payroll, so treat it as added capacity unless the business actually plans to reduce hours.

7. Pick One Task to Test

With a few candidates described and estimated, choose one to test first.

The best one to start with has measurable value, a point where a person reviews the result, and information the business is comfortable sending to an AI service. It also:

Is contained to one workflow or one team
Has someone who does the work and is available to help test it

It is tempting to start with the largest opportunity. A smaller one with a clear measure of success is often the better first choice, because it shows whether AI works with the information and people the business already has before a larger commitment is made.

The next step is usually a small proof of concept that tests the task on real examples against agreed success criteria. That process, and how to add the result to an application the business already runs, is covered in Adding AI to an Existing Application Without Rebuilding It.

Start With the Work, Not the Pressure to Use AI

The most useful AI projects begin with a specific task that is slow, repetitive, or error-prone, not with the question of where to use AI. The goal is to choose the simplest approach that fixes that task. For work that involves reading and interpreting varied information, that approach is often AI.