Frequently asked questions about custom AI development

It means designing a solution around a company’s specific processes, data, rules and integrations instead of adapting the business to an off-the-shelf tool.

It usually makes sense when there are specific processes, several integrations, in-house rules, internal data or needs that an off-the-shelf platform can’t cover.

When an existing tool solves the problem properly, the volume is very low or the expected benefit doesn’t justify the cost of development and maintenance.

Agents, automations, internal assistants, RAG systems, conversational tools, document processing, interfaces over data and specialized applications.

Yes. It can connect to ERPs, CRMs, databases, APIs, proprietary software, document management systems, calendars, email and other systems.

Yes. The architecture can define what each user can look up, which actions they can carry out and which information is restricted.

Not necessarily. Many projects use existing models combined with data, tools, RAG, rules and integrations.

Yes, with the test suite run first. Swapping models is proven, not promised: different models behave differently and sometimes the switch means making changes to the system.

Yes. We review what’s in production every week, because a system with a model inside can get worse without throwing any error. Every change also passes the test suite before it goes out.

By what the company gains, in euros: new revenue or avoided cost. After that come the percentage automated, errors avoided, answer quality, cost per operation and time saved.

It lets you adapt integrations, permissions, flows, experience and rules to your own processes. On top of that, the repository and the cloud are in the client’s name from day one. In return, it requires a larger upfront investment and maintenance.

Yes. The usual approach is to combine existing services, models, frameworks and APIs with in-house software.

Not always. It can make integrations and maintenance easier, but the project can be designed for organizations without a large technical team.

Yes. It’s common to start with one specific process and later expand to new integrations, departments or features.

Yes. It can be added as a new layer or module without rebuilding the whole application.

Yes, when the project needs the tool to appear under the client’s brand.

Yes. Isolation between organizations, permissions and separate data can be set up when the product or process requires it.

Yes. An architecture can pick different models or providers depending on the task, cost, accuracy or privacy requirements.

The model version is pinned, so a change on the provider’s side doesn’t reach production on its own. And the repository and the infrastructure are in your name from day one, so you aren’t dependent on us either.

Model usage runs on accounts in your company’s name, so you see any price change on your own bill and it doesn’t go through us. If switching models is worth it, the switch is tested against the test suite before any decision is made.