A useful evaluation does not ask how many models the vendor uses. It asks what problem they solve, how they integrate, who operates it, and what happens when it fails.
In this article +
Your lists
Define the problem and decision before hearing the pitch
If the team enters the evaluation without a use hypothesis and a buying criterion, the vendor sets the agenda. The starting point should be internal: which workflow the company wants to improve, what evidence it needs, and how much lock-in it can tolerate.
Compare architecture, not just the interface
A convincing demo can hide fragility in integrations, security, or data governance. Ask how it connects, what depends on third parties, which logs it provides, and what part of the system remains truly under customer control.
Request the integration diagram and external dependencies.
Ask for detail on permissions, traces, and exportability.
Clarify which capabilities are roadmap versus already live.
Test with a real case and uncomfortable data
The value test should use a real workflow, imperfect documents, and real constraints. If the vendor only shines with clean data and curated questions, they have not yet proved implementation capability.
Evaluate the operating model, not only initial delivery
Ask who supports changes, how incidents are handled, what metrics they report, and which capabilities the internal team must retain. Many problems do not appear at launch. They appear three months later.
Close with a scorecard, not a feeling
The final decision should leave comparable scores by criterion: fit to use case, integration, security, speed, switching cost, and support. Without that scorecard, the process rewards the best presentation, not the best operator.
We use necessary cookies for the site and, only with your permission, analytics (Google Analytics, Microsoft Clarity and PostHog when enabled) to improve the experience. Cookie policy · Privacy
Cookie settings
Use Activate all / Deactivate all per category. Expand for individual cookies.
kdx-cookie-consent
Kodex (first-party) · localStorage
Recordar categorías de cookies aceptadas o rechazadas (Aceptar / Rechazar / Ajustes).
kdx_session
Kodex (first-party) · cookie HTTP (HttpOnly, SameSite=Lax, Secure en producción)
Mantener la sesión autenticada de la comunidad Kodex (cuenta, listas guardadas, panel).
CDN / sesión de entrega
Infraestructura / CDN · cookie HTTP / sesión
Entrega segura del sitio, rendimiento y protección básica.
reCAPTCHA
Google · _GRECAPTCHA y relacionadas
Protección antispam en formularios públicos.
kdx-theme-override
Kodex (first-party) · localStorage
Recordar si el usuario forzó tema claro u oscuro.
_ga / _ga_*
Google Analytics 4 · cookie HTTP
Medición agregada de audiencia y uso del sitio (páginas, eventos).
Microsoft Clarity
Microsoft · cookies / almacenamiento de sesión
Mapas de calor, clics y reproducción de sesiones para mejorar UX.
PostHog
PostHog · cookie / localStorage
Analítica de producto y eventos de conversión (si está configurado).