Insights · 9 min read

When do you need custom AI software?

Not every process needs artificial intelligence. And not every problem calls for new software.

In many cases it’s enough to improve internal organisation, correctly configure the tools already in place, or introduce a simple automation.

A custom AI system makes sense when the process is frequent, complex, and important enough that it can’t be handled reliably through email, spreadsheets, and manual checks.

This guide helps you understand when it’s worth looking deeper and when, instead, building software would be a premature investment.

Software built without this question is the most expensive kind of shelfware: paid for, delivered, never really used.

When it isn’t needed

The volume is too low

If a task is carried out a few times a month and takes little time, building a dedicated system could cost more than the problem it’s meant to solve. A structured spreadsheet, a clearer procedure, or an existing tool is better. Technology should reduce a real cost, not add complexity to a marginal task.

The process keeps changing

Software translates a process into precise rules, states, permissions, and behaviours. If the team is still changing the way it works every month, developing too early risks freezing a process that isn’t yet mature. Before automating it, you may need to observe, simplify, and stabilise it.

The problem is organisational

If two departments don’t share responsibilities, criteria, or ways of working, a new system doesn’t automatically resolve the conflict. It can make the steps more visible, but it can’t replace an organisational decision. Digitising a poorly defined process often just moves the same confusion inside an interface.

Five concrete questions to assess the process

How many people are involved before the information becomes useful?

When the same piece of data is read, copied, checked, and forwarded by several people, time, the chance of error, and dependence on individual operators all increase. The problem becomes particularly significant when no one has a complete view of the state of the case.

How often is it repeated?

A task repeated every day can justify a different investment than a procedure carried out a few times a year. Frequency, however, isn’t the only criterion: even a rare process can deserve a dedicated system when an error brings high costs, liability, or lost opportunities.

Do documents and data always arrive in the same format?

The processes hardest to automate aren’t the ones with the most data, but the ones where information arrives through PDFs, emails, forms, attachments, and different structures. Here AI can help classify, extract, and organise the information, but it must sit inside rules, checks, and outcomes handled explicitly.

Do you need to reconstruct how a decision was made?

When a process involves requirements, assessments, compliance, authorisations, or important documents, getting a result isn’t enough. You may need to know:

which information was used;
which checks were carried out;
which anomalies were detected;
who approved the result;
which steps remained under human control.

In these contexts, traceability and the ability to verify are part of the system, not optional features.

Is there already a tool that should solve the problem?

Before building software, you need to understand why the existing tools aren’t used or aren’t enough. The limit might come from:

incomplete configuration;
missing integrations;
a poor user experience;
disproportionate costs;
lack of specific features;
organisational resistance.

If a standard product can properly solve the problem, building a new one isn’t necessarily the better choice.

When custom software starts to make sense

A dedicated system becomes a real option when several conditions come together:

the process repeats with significant frequency;
it involves different people, documents, and tools;
it requires checks or rule-based decisions;
errors generate costs, delays, or risks;
the state of the activities is hard to reconstruct;
there are numerous manual steps;
the current systems don’t talk to each other;
the process needs to be able to evolve over time;
human control over critical steps must be maintained.

No single signal is enough on its own. The decision depends on the balance between the cost of the problem, the stability of the process, the expected value, and the complexity of the solution.

Automation, web app, or AI software?

Not every process needs the same architecture. Often the right solution is the simplest one.

A simple automation, when

the flow is linear;
the rules are stable;
the data is already structured;
the tools offer suitable APIs;
no new interface is needed;
errors are easy to catch.

Make, n8n, and API integrations connect existing platforms without building a complete system.

A web app, when

you need a central place to work;
there are users with different roles;
you need to manage states, cases, documents, and approvals;
the team needs dashboards and internal tools;
information needs to be organised consistently.

An AI component, when

the information isn’t fully structured;
you need to read or classify different documents;
you need to extract relevant elements from large amounts of content;
the system needs to prepare drafts, assessments, or summaries;
some decisions can be supported, but not delegated.

AI doesn’t automatically replace traditional software. In most operational systems, it’s a component placed inside an architecture also made of databases, deterministic rules, interfaces, permissions, integrations, and checks.

What the investment depends on

The cost of a custom system depends less on the presence of artificial intelligence and more on the real complexity of the process. What matters most:

number of users, roles, and permissions;
amount of features and operational steps;
quality and availability of the data;
number and reliability of the integrations;
variability of the documents;
security and traceability requirements;
level of human control needed;
testing, acceptance, and maintenance procedures;
consequences of an error or an interruption.

That’s why we avoid generic estimates before understanding at least the main flow, the exceptions, and the expected result. A simple automation, an operational web app, and a complex AI system solve very different problems and require levels of work that aren’t comparable.

The first assessment also serves to understand whether the investment is proportionate to the problem. When it isn’t, we prefer to say so before starting.

Systems don’t always fail in an obvious way

A system can seem effective during a demo and fail when it meets real data, larger volumes, or unforeseen situations. Some problems don’t produce an obvious error: they produce a plausible but wrong result.

The document that differs from the examples

The system works on the files used during development, but misreads scans, incomplete attachments, or structures coming from different senders.

The missing value treated as an answer

The absence of information is interpreted as a negative outcome, instead of being flagged as insufficient data.

The prototype can’t hold the operational flow

A demo can work on a few cases. In production, duplicates, concurrency problems, timeouts, delays, or unexpected costs emerge.

The result looks correct, but can’t be verified

The output is well phrased, but it’s not possible to reconstruct which data led to that conclusion.

An external service fails silently

An API returns an incomplete response, but the workflow continues and records a seemingly completed case.

The AI decides where it should have flagged

A serious system must also know when it doesn’t have enough information and when it needs to ask for human review.

Producing a few correct results isn’t enough

Before delivery, we define, based on the project:

what the system must do;
which results are considered correct;
which cases must be blocked;
when human review must be requested;
which errors must be logged;
which limits can’t be removed;
which aspects it wasn’t possible to verify.

Verification is built around the real risk of the process. A system that prepares marketing content doesn’t require the same level of control as a system that checks requirements, documents, or information used in an operational decision.

A simplified example

Scenario	Expected behaviour
Complete, readable document	Extracts the data and continues
Required information missing	Requests review
Data inconsistent with each other	Flags the anomaly
Unrecognisable document	Blocks the process
External service unavailable	Logs the error and doesn’t lose the data
Insufficient confidence	Doesn’t produce an automatic decision

The principle

When the system doesn’t have enough to go on, it must flag it clearly instead of completing the process at all costs.

Human control isn’t a fallback

Leaving some decisions to the team doesn’t mean the system is incomplete. It means correctly designing the boundary between what can be automated and what requires responsibility, experience, or contextual judgement.

A good system can:

gather the information;
apply checks;
highlight anomalies;
prepare a result;
suggest an action;
record the process.

The final decision can stay with a person when the risk, the regulations, or the context require it.

Before building, we understand the process

We don’t start from the question «Where can we put AI?». We start from more concrete questions:

Where is time lost?
Where do errors occur?
Which information is copied multiple times?
Which decisions follow recognisable rules?
Where is visibility missing?
Which steps must stay under human control?
How much does the problem cost today?
What result would justify the investment?

Sometimes the answer is AI software.

Sometimes it’s a web app without AI.

Sometimes it’s enough to connect the existing tools better.

And in some cases the best choice is to build nothing at all.

Describe the process in a few lines

There’s no need to prepare a technical brief. You can simply tell us what happens today, who’s involved, where slowdowns or errors occur, and which tools are used.

We’ll give you an honest first assessment to understand whether it makes sense to look deeper. The answer might be:

you need custom software;
an automation may be enough;
there’s probably an off-the-shelf tool already;
the process needs to be better defined;
it doesn’t yet seem to justify a technology investment.

Request received.

Thank you. We’ll read the process you’ve described and reply with an honest first assessment, even if the answer is «you don’t need it».