Digital Consulting Plus · Technology Blueprint

Tecnología aprobada con contexto, límites y evidencia.

DCP Flow define cómo decidimos, ejecutamos, validamos y aprendemos. El Technology Blueprint define las familias tecnológicas activas y sus límites. Elegir una tecnología sigue requiriendo contexto, Solution Discovery y, cuando aplica, un ADR aceptado.

DCP Flow y Technology Blueprint son capas distintas

Los Blueprints definen familias activas y su madurez institucional. EspoCRM está ADOPTED como CRM liviano de DCP; eso no lo hace obligatorio para cada proyecto. La selección sigue pasando por Solution Discovery, Project Truth y, cuando aplica, un ADR.

Technology Families

Blueprints activos

Web / Astro

EVOLVING

QUÉ: Astro + TypeScript, static-first y contenido estructurado.
POR QUÉ: Entrega rápida, SEO/AEO, bajo runtime y superficie operacional reducida.
CUÁNDO: Webs corporativas, landings, microsites, documentación y portales content-first.
BOUNDARY: Si el dominio se vuelve transaccional u operacional, se reclasifica antes de convertir Astro en business application.

Laravel

VALIDATED / EVOLVING

QUÉ: Plataforma de aplicación PHP para dominios de negocio y SaaS.
POR QUÉ: Ecosistema coherente para lógica de dominio, autorización, UI server-driven, testing y delivery reproducible.
CUÁNDO: SaaS, aplicaciones operacionales, plataformas con dominio relevante y APIs de aplicación.
BOUNDARY: No es la opción por defecto para sitios estáticos, ERP ni utilidades mínimas. La baseline se valida en bootstrap.

EspoCRM

ADOPTED / EVOLVING BY EVIDENCE

QUÉ: CRM open source liviano, self-hosted y extensible para lifecycle comercial desacoplado.
POR QUÉ: Evita construir un mini CRM propio o forzar responsabilidades CRM dentro de un ERP cuando el proyecto necesita pipeline, actividades, cuentas, contactos y oportunidades.
CUÁNDO: Proyectos donde un CRM externo desacoplado ofrece mejor fit que BUILD o que usar el ERP como CRM.
BOUNDARY: ADOPTED no significa obligatorio. Core/vendor read-only; preferir configuración, metadata, roles, workflows e integraciones soportadas. La entidad CRM sigue siendo contextual.

Odoo Community 17 / 18 / 19

EVOLVING

QUÉ: Blueprint ERP sobre Odoo Community, version-aware y OCA-first.
POR QUÉ: Extensibilidad modular con ecosistema ERP amplio sin convertir el core en código propio.
CUÁNDO: Proyectos cuya necesidad encaja con Odoo Community y la edición seleccionada.
BOUNDARY: Community only. Core read-only; cambios mediante mecanismos de extensión compatibles y módulos permitidos.

ERPNext / Frappe 15 / 16

EVOLVING

QUÉ: Blueprint ERPNext/Frappe con versión detectada y fijada por proyecto.
POR QUÉ: Plataforma ERP/app-first con custom apps y topología operativa explícita.
CUÁNDO: ERPNext/Frappe cuando el fit funcional y operativo justifica la plataforma.
BOUNDARY: ERPNext Core y Frappe Core read-only; shared hosting típico no soportado por su runtime.

Dolibarr 22

EVOLVING

QUÉ: Blueprint ERP/CRM module-first para Dolibarr.
POR QUÉ: Extensión controlada sobre una plataforma ERP/CRM ligera.
CUÁNDO: Escenarios donde Dolibarr 22 ofrece mejor fit que construir o adoptar una plataforma mayor.
BOUNDARY: Core read-only; lógica propia en módulos y extensiones compatibles.

Python

EVOLVING

QUÉ: Servicios, utilidades, automatizaciones e integraciones Python bounded.
POR QUÉ: Adecuado para servicios especializados, integración, tooling y APIs cuando el problema lo justifica.
CUÁNDO: Servicios/utilidades acotados y componentes que no necesitan una plataforma de aplicación mayor.
BOUNDARY: Python standalone no equivale a Odoo. No crecer por inercia hasta convertirse en mini-framework o mini-ERP.

PHP nativo

EVOLVING

QUÉ: Utilidades e integraciones PHP lightweight/bounded.
POR QUÉ: Permite resolver piezas pequeñas sin introducir una plataforma completa.
CUÁNDO: Integraciones, endpoints o utilidades claramente acotadas.
BOUNDARY: No sustituye Laravel cuando existe dominio de aplicación relevante; no crecer por inercia a mini-framework.

Baseline Laravel actual

Referencia vigente, no promesa eterna. Las compatibilidades se validan durante bootstrap.

PHP 8.4Laravel 13Livewire 4BladeAlpine.jsTailwind CSS 4.2+Flux UI 2Pest 4PintLarastan / PHPStanNode.js 22 LTSDocker ComposeGitHub Actions

Decisión de base de datos

PostgreSQL

Preferido en greenfield sin restricciones cuando DCP controla la arquitectura.

MySQL / MariaDB

Válidos cuando producto, plataforma, hosting, compatibilidad, equipo o costo lo justifican.

SQLite

Contextual y bounded donde el Blueprint/plataforma lo soporta —por ejemplo, la baseline Laravel—; no es obligación ni default empresarial.

Integración y automatización

REST APIs y Webhooks son patrones de integración. MCP se gobierna mediante el Tool & MCP Registry y su estado real. La presencia en un catálogo no implica adopción ni autorización.

REST APIs

Boundary explícito entre sistemas y capacidades.

Webhooks

Eventos e integración desacoplada cuando corresponde.

MCP

Capability gobernada por registro y estado. Los MCP shortlist actuales permanecen EXPERIMENTAL hasta POC.

Engineering Toolchain

GitHub

Source control, PRs, trazabilidad y gobierno del repositorio.

GitHub Actions

CI y Quality Gates cuando el repositorio los implementa.

Docker / Compose

Baseline preferida para reproducibilidad cuando el stack lo permite; alternativa documentada si no aplica.

QA por stack

Testing, análisis estático, lint y browser/runtime evidence según Blueprint y riesgo.

Cloud y runtime pragmáticos

DCP Flow no equivale a GCP ni a AWS. El target cloud debe ser explícito y la solución razonablemente portable cuando el contexto lo permite. Runtime readiness exige startup reproducible, health checks, estado persistente, secretos fuera del repo, compatibilidad con CI/testing, backup/recovery y evidencia proporcional al riesgo.

Observabilidad y analytics

Observabilidad es una capacidad exigible por riesgo y Blueprint; el proveedor concreto se selecciona por proyecto. 07C no eleva GlitchTip, PostHog, OpenReplay o Metabase a “stack empresarial aprobado” sin una declaración normativa transversal inequívoca. Metabase, cuando sea seleccionado, es BI/reporting y nunca business logic.

Evaluación ≠ adopción

El Tool & MCP Registry mantiene candidatos como GitHub MCP, n8n Instance MCP, Google Cloud MCP, AWS MCP y Hostinger MCP en estado EXPERIMENTAL hasta POC. Hermes y AnythingLLM tampoco se presentan aquí como stack aprobado mientras permanezcan bajo evaluación/ADR.

Fuente normativa

Blueprints activos, runtime/deployment profiles, Standards ACCEPTED y Tool & MCP Registry de digitalconsultingplus/dcp-flow. La página pública resume; el repositorio normativo controla.