Digital Consulting Plus · Technology Blueprint

Approved technology with context, boundaries and evidence.

DCP Flow defines how we decide, execute, validate and learn. The Technology Blueprint defines active technology families and their boundaries. Choosing a technology still requires context, Solution Discovery and, when applicable, an accepted ADR.

DCP Flow and the Technology Blueprint are different layers

Blueprints define active technology families and their institutional maturity. EspoCRM is ADOPTED as DCP’s lightweight CRM; that does not make it mandatory for every project. Selection still goes through Solution Discovery, Project Truth, and an ADR when applicable.

Technology Families

Active Blueprints

Web / Astro

EVOLVING

WHAT: Astro + TypeScript, static-first and structured content.
WHY: Fast delivery, SEO/AEO, low runtime complexity and reduced operational surface.
WHEN: Corporate sites, landings, microsites, documentation and content-first portals.
BOUNDARY: If the domain becomes transactional or operational, reclassify before turning Astro into a business application.

Laravel

VALIDATED / EVOLVING

WHAT: PHP application platform for business domains and SaaS.
WHY: A coherent ecosystem for domain logic, authorization, server-driven UI, testing and reproducible delivery.
WHEN: SaaS, operational applications, domain-heavy platforms and application APIs.
BOUNDARY: Not the default for static sites, ERP or tiny utilities. Current baseline compatibility is validated at bootstrap.

EspoCRM

ADOPTED / EVOLVING BY EVIDENCE

WHAT: Lightweight, self-hosted and extensible open-source CRM for a decoupled commercial lifecycle.
WHY: Avoids building a mini CRM or forcing CRM responsibilities into an ERP when the project needs pipeline, activities, accounts, contacts, and opportunities.
WHEN: Projects where a decoupled external CRM fits better than BUILD or using the ERP as the CRM.
BOUNDARY: ADOPTED does not mean mandatory. Core/vendor is read-only; prefer supported configuration, metadata, roles, workflows, and integrations. CRM entity choice remains contextual.

Odoo Community 17 / 18 / 19

EVOLVING

WHAT: Version-aware, OCA-first ERP Blueprint for Odoo Community.
WHY: Modular extensibility with a broad ERP ecosystem without owning the core.
WHEN: Projects whose requirements fit Odoo Community and the selected edition.
BOUNDARY: Community only. Core read-only; use compatible extension mechanisms and allowed modules.

ERPNext / Frappe 15 / 16

EVOLVING

WHAT: ERPNext/Frappe Blueprint with project-detected and pinned version.
WHY: ERP/app-first platform with custom apps and explicit operational topology.
WHEN: When functional and operational fit justifies ERPNext/Frappe.
BOUNDARY: ERPNext Core and Frappe Core remain read-only; typical shared hosting is not supported.

Dolibarr 22

EVOLVING

WHAT: Module-first ERP/CRM Blueprint for Dolibarr.
WHY: Controlled extension on a lighter ERP/CRM platform.
WHEN: When Dolibarr 22 fits better than custom build or a larger platform.
BOUNDARY: Core read-only; custom logic belongs in compatible modules/extensions.

Python

EVOLVING

WHAT: Bounded Python services, utilities, automation and integrations.
WHY: Suitable for specialized services, integration, tooling and APIs when justified.
WHEN: Bounded components that do not require a larger application platform.
BOUNDARY: Standalone Python is not Odoo; do not let lightweight code drift into a mini-framework or mini-ERP.

Native PHP

EVOLVING

WHAT: Lightweight/bounded PHP utilities and integrations.
WHY: Solves small pieces without introducing a full application platform.
WHEN: Clearly bounded integrations, endpoints or utilities.
BOUNDARY: Does not replace Laravel for meaningful application domains; no mini-framework drift.

Current Laravel baseline

Current reference, not a permanent promise. Compatibility is validated during bootstrap.

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

Database decision

PostgreSQL

Preferred for unconstrained greenfield when DCP controls the architecture.

MySQL / MariaDB

Valid when product, platform, hosting, compatibility, team or cost justify them.

SQLite

Contextual and bounded where the Blueprint/platform supports it —for example the Laravel baseline—; not a company-wide default.

Integration and automation

REST APIs and Webhooks are integration patterns. MCP is governed through the Tool & MCP Registry and its actual status. Catalog presence does not imply adoption or authorization.

REST APIs

Explicit boundary between systems and capabilities.

Webhooks

Events and decoupled integration when appropriate.

MCP

Registry-governed capability. Current shortlisted MCPs remain EXPERIMENTAL until POC.

Engineering Toolchain

GitHub

Source control, PRs, traceability and repository governance.

GitHub Actions

CI and Quality Gates where implemented by the repository.

Docker / Compose

Preferred reproducibility baseline when the stack fits; documented equivalent otherwise.

Stack-specific QA

Testing, static analysis, lint and browser/runtime evidence according to Blueprint and risk.

Pragmatic cloud and runtime

DCP Flow is not synonymous with GCP or AWS. The cloud target must be explicit and workloads should remain reasonably portable when context allows. Runtime readiness requires reproducible startup, health checks, persistent state, secrets outside the repository, CI/testing compatibility, backup/recovery and risk-proportional evidence.

Observability and analytics

Observability is a capability required according to risk and Blueprint; the concrete provider is project-selected. Sprint 07C does not promote GlitchTip, PostHog, OpenReplay or Metabase to “enterprise approved stack” without an unambiguous cross-project normative declaration. When selected, Metabase is BI/reporting, never business logic.

Evaluation ≠ adoption

The Tool & MCP Registry keeps candidates such as GitHub MCP, n8n Instance MCP, Google Cloud MCP, AWS MCP and Hostinger MCP EXPERIMENTAL until POC. Hermes and AnythingLLM are likewise not presented as approved stack while they remain evaluation/ADR subjects.

Normative source

Active Blueprints, runtime/deployment profiles, ACCEPTED Standards and the Tool & MCP Registry in digitalconsultingplus/dcp-flow. This public page summarizes; the normative repository controls.