Custom AI Agent: Tailored Development

Faced with a precise business need, two options compete: adopting an existing generic AI tool, or having a custom solution developed that fits your context exactly. At Retinax, a group of ophthalmology centers with 25 employees, no generic tool could have met the need: consolidating medical and financial data scattered across several centers and several siloed business software packages. A good project starts with a simple question: does the need really justify a development, or would an existing tool be enough? Here is why, in some cases, custom development is the right choice, how the Daxboard project unfolded, what the steps of this type of development are and what influences its budget.

Why choose custom development rather than a generic tool

Business logic too specific for a standard tool. At Retinax, the critical data (consultations, surgeries, patient flows, financial indicators) each lived in its own silo, with manual Excel exports and business software that did not communicate with each other.

Deep integration with existing systems. A custom agent can connect precisely to your internal databases, whereas a generic tool often imposes its own technical constraints.

Its own commercial potential. The ambition of the Retinax project was twofold from the start: meet the group's immediate needs, while laying the foundations of a solution that could potentially be sold to other medical organizations.

The Retinax case: Daxboard, a custom application designed to evolve

Qolaig designed and developed Daxboard, a custom web application based on an existing design and connected to the group's internal databases through a secure infrastructure. The project is built around three modules: a central dashboard that aggregates key indicators in real time (volume of consultations, surgical activity, performance by practitioner), an integrated accounting module for entering and validating financial flows, and complete business configuration allowing each center to set up the tool according to its own protocols.

The architecture was designed from the outset as multi-tenant, with a modular deployment system per center, allowing Retinax to consider selling the solution to other medical organizations without a technical overhaul.

Results: a single interface to manage all of the group's centers, 3 modules covering 100% of the identified needs, key indicators available in real time instead of manual weekly reports before, and an architecture ready for external SaaS commercialization.

The steps of a custom AI agent project

1. Scoping the need. Define precisely the task to automate, the rules to respect and the systems to connect.

2. Technical design. Choose the right architecture: which model, which method of accessing data, what level of autonomy to give the agent. Our article on RAG in the enterprise details one of these common technical building blocks.

3. Development and testing. Build the agent through iterations, testing it on real cases.

4. Gradual deployment. Launch first on a limited scope before rolling it out more widely.

5. Monitoring and maintenance. A custom agent is never a frozen project: its behavior must be monitored and adjusted over time.

How to prepare a useful specification

A good specification fits in a few pages. It describes the problem to solve and who experiences it, the users and their daily uses, the systems and data concerned, the business rules to respect, the security and confidentiality constraints, the expected result with a quantified indicator, and the desired budget and timeline. It distinguishes what is essential from what is desirable: this makes it possible to deliver a useful first phase quickly, then enrich it. The more precise it is about special cases (exceptions, validations, rights), the fewer surprises there are during development.

The risks of custom development

Scope creep. Every new request along the way lengthens the project. A list of features “for later” and regular arbitration limit this drift.

Dependence on a provider. Undocumented code, or code hosted by the provider, makes it difficult to take the project over. Require documentation, access to the code and ownership of the data.

Insufficient adoption. A technically successful solution can remain underused if the teams were not involved. Involve a few users from the design stage.

Forgotten maintenance. Applications, models and connectors evolve. Without a maintenance budget, the solution gradually degrades.

When custom development is not the right choice

Custom development is not always the right answer. If the need is standard, a tool on the market already covers it and your teams can adopt it effortlessly, it is better to start with that tool. An integrated copilot, like the one described in our article on the AI copilot in the enterprise, can be an inexpensive first step.

Custom development becomes relevant when the business logic is too specific, when several systems must communicate, or when the solution must become an asset of the company in its own right, like Daxboard at Retinax. A good reflex is to test first on a reduced scope: if the standard tool is enough, the project stops there, at no extra cost. Otherwise, this test clarifies exactly what needs to be developed.

The indicators to judge the project's success

A custom project is judged on indicators set before development. The time saved on the targeted task, measured before and after. The adoption rate, meaning the share of intended users who actually use the tool every week. The quality of the results, tracked through the number of manual corrections needed. Finally, stability: the number of incidents and the time to resolve them. Four indicators tracked every month are enough to know whether the investment is keeping its promises or whether adjustments are needed.

What influences the budget of a custom development

The cost depends mainly on the complexity of the business logic to reproduce and on the number of systems to connect. The diversity of the projects carried out by Qolaig, from a simple connector to a complete platform like Daxboard, shows how wide the range is. Linking this budget to the expected gain, in time saved or errors avoided, is the best way to decide whether the investment is worth it.

According to Deloitte, employees' access to AI has increased sharply in recent years, but this acceleration makes it all the more necessary to build developments designed to last, rather than one-off tools that quickly become obsolete.

FAQ

Does a custom AI agent replace existing business software?
Not necessarily: at Retinax, Daxboard unifies and centralizes existing tools rather than replacing them one by one. Choosing the right partner for this kind of project matters as much as the technology: see our guide on how to choose an AI agency.

How long does it take to develop a custom AI agent?
For a well-defined scope, generally allow several weeks between scoping and the first deployment in real conditions. A more ambitious project like Daxboard, designed to evolve toward external commercialization, is built over a longer period. Our article on the AI consultant in the enterprise helps decide where to start.

At Qolaig, our Workshop → Build → Run methodology frames this type of project before any technical investment. Let's talk about your project.