Skip to content
Giallo

DIY AI or agency: how to decide

When to build AI in-house and when to use a provider: real costs, required skills and the risks of each approach.

Reading time: 9 min

Comparison of internal AI development and reliance on an external vendor

The choice between building internally and relying on a supplier is almost always made on the price, and that is the wrong criterion. DIY doesn't cost zero: it costs the time of those who do, and that time is subtracted from something else.

The correct criterion is another: how critical the process is, and what happens when the system breaks down at seven o'clock in the evening.

In summary

  • DIY has a real cost: the days of those who build it.
  • Visual tools work well on Linear Flows, bad on exceptions and deep integrations.
  • The main risk of DIY is the dependence on a person.
  • The supplier agrees when the process touches customers, money or sensitive data.
  • The mixed scenario —supplier for the core, interior for evolution —is often the best.
  • Code properties, documentation, and credentials must be agreed upon before.

The Honest Comparison

Do it yourself Supplier
Visible cost Instrument Canon Quote
Real cost Internal days Quote + internal days
Timings Variables, often long Definitions
Error Management Often absent Part of the work
Documentation Rare To be expected
Continuity Tied to a person Contractual
Suitable for Simple, non-critical flows Processes that matter

The line "real cost" is the one that overturns many decisions. Fifteen days of an internal person are worth, at the company cost, a figure that often comes close to an external quote. with the difference that the quote also includes error management and testing.

When DIY works well

Good internal candidates

  • Linear flows without exception
  • Internal use, not customers
  • If it breaks, it is done by hand
  • Non-sensitive data
  • There are those who have allotted time, not just want

Better a provider

  • The system talks to customers
  • Tap invoices, payments, orders
  • Needs integration with management software
  • There is personal or confidential data
  • The process can't stop

The summary criterion is simple: If it breaks, just go back to doing it by hand, the DIY is reasonable. If when it breaks, someone notices it outside the company, no.

The Risk That Nobody Considers

In SMEs the internal system almost always builds it the most curious person, in the clippings, without documenting. It works, everyone is happy, and for a year it's fine.

Then that person changes roles, goes on vacation at the wrong time or leaves the company. It remains a system that no one can modify, with unwritten logic anywhere and credentials registered to a personal account. At the first break it is abandoned, and the work done is lost.

Warning If you choose the in-house route, enforce two rules from day one: service credentials must belong to the business, and there must be a page explaining what the system does and where to make changes. This is twenty minutes of work that saves the project when that person is no longer there.

The mixed scenario

In practice the configuration that works best in SMEs is hybrid: the supplier builds the core —integrations, error management, critical parts.and internal resources deal with extensions, content and ordinary maintenance.

For functions, three conditions are agreed at the beginning:

  1. The system is documented readable by those who did not write it.
  2. The code and data I'm from the company, in writing.
  3. The credentials services are registered to the company, not to the supplier.

These are three points that are easily obtained before signing and with difficulty after. Those who work well have no problem in granting them.

Practical examples

Automation of internal notifications. A flow that alerts the commercial when a request arrives. Linear, internal, non-critical. Perfect for DIY with visual tools: half a day and works.

Assistant responding to customers on WhatsApp. It touches customers, requires integration with management software, and if it goes wrong the market sees it. Here DIY exposes you to a disproportionate risk compared to saving.

Extracting data from invoices. Gray area. If it is needed for an internal statistic, it can be done internally. If it feeds the accounting, no: a silent error propagates and is discovered late.

The Skills You Really Need

When you evaluate the inland road, you think about technical skills. They are the least rare. Three more are missing most often in SMEs, and it is worth checking them honestly before deciding.

To be able to say no to the system. Those who build must be able to decide that a certain exception will not be handled automatically, because it costs more than it is worth. It is a decision that requires a view of the process and a bit of authority: those who suffer it end up building a system that tries to do everything and does nothing right.

Think about what can go wrong. It's the difference between a prototype and a system. What happens if the service does not respond, if the document is unreadable, if a hundred requests arrive in a minute, if someone writes in a different language. It's not programming: it's mentality, and not everyone has it.

Document while building. The rarest and most decisive competence for the survival of the project.

If these three skills in the company are not there, the internal road can still work for simple automations, but it becomes risky as soon as the system touches something important.

How to Evaluate a Supplier

If you choose the external road, the signals to look at are not the mentioned technologies but the way it addresses your problem.

Good Signals

  • Ask questions about the process before proposing
  • It tells you when something doesn't want to do it
  • Explicitly name error handling
  • Talk about what happens after release
  • He asks who will follow him internally

Signals to be explored

  • List technologies instead of results
  • Promises very short time without analysis
  • He never mentions exceptions
  • Avoid the question of code ownership
  • Proposes the same solution to different problems

The most reliable signal ever is the second of the left column: a supplier that advises against a piece of work is showing that it looks at your result and not the size of the quote.

What remains of the company in one case and the other

It is also worth looking at the choice from the point of view of what you possess in the end, because it is an aspect that is rarely evaluated and that counts in the long run.

With the DIY remains the Internal knowledge: someone in the company has understood how it works and can intervene. It is a real asset, provided that it is documented and not concentrated in one person.

With the supplier remains the system, and knowledge remains predominantly out. It is acceptable if the contract provides for documentation and ownership of the code; it becomes a problem if you have not asked for it.

The mixed configuration is the one that allows you to have both, but it must be built on purpose: it means asking the supplier to work in an understandable way and to transfer knowledge, not just to deliver something that works.

The overall cost framework is in how much AI costs in the company, the voices that escape in hidden costs of AI projects, and the method of risk assessment in How to Assess the Risks of an AI System.

Mistakes to Avoid

  • Comparing tool subscription fees with a quote. The cost of days is missing.
  • Letting the project depend on one person. It is the most common failure.
  • Using personal credentials. When the person comes out, the access also comes out.
  • Not documenting anything. An undocumented system has a short lifespan.
  • Not agreeing on code ownership. It must be written first.
  • Doing customer-facing work in-house. Savings do not cover risk.

How to apply it in the company

For each candidate project, answer three questions before deciding who will do it: if it breaks, will anyone outside the company notice? Does it need connecting to business management software? Who will maintain it a year from now?

A single "yes" to the first two, or a "I don't know" to the third, indicates the way of the supplier. Three tranquilizing responses indicate that internally one can do so, provided that one assigns explicit time to someone instead of hoping for goodwill.

The full economic assessment is in AI budget for SMEs, and the voices that escape the quotations in hidden costs of AI projects.

Finally, it is worth remembering that this choice is not final. Many companies start internally on simple automations, learn what they really need, and rely on the outside only when they get to processes they can't handle. It is a sensible path, provided that the work done internally is documented enough to be explained to those who take over.

Conclusion

The choice between DIY and supplier is not decided on the price, because the price of DIY is hidden in the days of those who build it. It is decided on the criticality of the process and continuity.

The rule that sums it all up: do in-house what you can do manually, if it breaks, without anyone noticing. Delegate the rest.

If you want to go from testing with ChatGPT to an AI system integrated into business processes, Giallo Studio custom designed agents and automations.

Giallo Studio guides: methodology and sources

How we apply it in the company

Related resources

AI consulting services and process automation

Other direct comparisons

The same criteria applied to other model pairs.

FAQ

Can you build an AI system internally without developers?

For simple automations, yes: visual tools let you connect services and add AI steps without writing code. They work well for linear workflows. They become fragile when you need to handle many exceptions, integrate deeply with business management systems, or manage errors properly.

How much does DIY really cost?

The cost is not zero: it is the time of the person doing it, taken away from their normal work. If someone spends fifteen working days building something, the project has cost fifteen days at that person’s cost to the business. Comparing it with an external quote solely on the tools’ subscription fees leads to the wrong conclusion.

What is the main risk of DIY?

Dependence on one person. In most SMEs, the system is built by whoever is most curious, often without documentation. If that person changes role or leaves the company, the business is left with a system nobody knows how to modify, which is abandoned the first time it breaks.

When is it definitely worth relying on a supplier?

When the system involves customers or money, when integrations with business management systems are needed, when data is sensitive, and when the process is critical. In those cases, error handling and traceability are worth more than savings on the development cost.

Can I combine the two approaches?

It is often the best choice: a provider handles the system’s core and integrations, while internal resources handle extensions and routine maintenance. However, the provider must deliver something understandable and documented, and this needs to be agreed at the outset.

How do I avoid being tied to the supplier?

Agree from the beginning who owns the code and data, ask that the system be documented in a legible way and that the credentials of the services are registered to your company. These are three points that are negotiated first and become difficult to obtain later.

Put it into practice

Let's turn this guide into your first live workflow.

Tell us what process you want to lighten: we evaluate feasibility, return and first operational step.