Design
constitution.
Tu empresa no es plantilla.
Tu software tampoco.
Lo que vive aquí dentro.
Este documento consolida el sistema operativo de DevZen Solutions v2.1 — manifiesto, voz, vocabulario, paleta, tipografía y reglas de aplicación — en una sola pieza ratificable. No inventa nada; pone bajo el mismo techo lo que ya quedó aprobado.
ManifiestoQué somos, contra qué, para quién.
DevZen Solutions es una software house premium. Filial técnica de Nümia Group. Construimos plataformas, sistemas y automatizaciones a la medida — con la disciplina de un equipo de Silicon Valley y la sensibilidad de operación de quien ha levantado un negocio en LATAM. No vendemos horas. Vendemos resultados que se quedan.
Para fundadores, COOs y directores de tecnología en LATAM que dejaron de querer "una agencia más" — quieren un equipo que entienda su negocio, proponga, y construya software que aguante el crecimiento.
Contra el outsourcing barato que entrega código que nadie puede mantener. Contra los freelancers que desaparecen al go-live. Contra las consultorías grandes que cobran enterprise y entregan PowerPoint. Contra el "ya quedó" sin pruebas, sin documentación, sin handoff.
Tu empresa no es plantilla.
Tu software tampoco.
Si todo lo anterior se redujera a una frase tatuada en la puerta del estudio, sería esa. Cada cliente entra con una operación distinta, un equipo distinto, márgenes distintos y una historia distinta. Lo que entregamos refleja eso — o no lo entregamos.
Las cinco promesas. En este orden, no es casual.
La calidad del código no se negocia. Lo que entregamos es lo que nosotros usaríamos en producción.
Automatizamos lo que se pueda automatizar. El equipo humano se enfoca en lo que solo un humano debe decidir.
Cada decisión técnica se justifica en margen, tiempo, riesgo o flujo. Hablamos de ROI, no de stack.
Si la idea inicial del cliente no es la correcta, lo decimos antes, no después.
El cliente sale de un proyecto DevZen más grande, más eficiente y más automatizado de lo que entró.
El negocio que sale de un proyecto con DevZen no es el mismo que entró. Promesa completa · cierre de manifiesto
Los principios operativosCómo se aplican las promesas a un mockup, un copy, un spec.
Las cinco promesas, traducidas a una pregunta concreta que se le hace a cada entregable antes de salir. Si la prueba falla, el entregable se reescribe. Si pasa, se firma.
Cada repo lleva tests, documentación y un runbook antes de cerrarse. El demo no es un atajo: es una vista parcial de algo que ya está hecho bien.
Pipelines, generación, QA y reportes se automatizan por default. El criterio humano se reserva para diseño de producto, riesgo, ética y trato con el cliente.
No defendemos un stack por gusto. Defendemos un stack porque ahorra n horas/semana, recorta x% de costo de hosting, o reduce un riesgo identificado a un riesgo manejable.
No firmamos un alcance que sabemos que no va a sobrevivir al primer cambio del mercado. Antes de cotizar, validamos. Si hay que reescribir el brief, se reescribe.
El último entregable no es un repo: es un cliente con más eficiencia, más automatización y más capacidad operativa que cuando empezamos. Si no podemos demostrar eso con datos, no firmamos el cierre.
Recomendamos X porque Y. Frase firma DevZen · estructura de toda recomendación
Lo que entregamos hoy es lo que usaríamos en producción mañana. Frase firma DevZen · cierre de propuesta
Las cinco pruebas se corren en orden: superioridad técnica primero (¿está bien hecho?), automatización (¿estamos haciendo a mano lo que la máquina puede hacer?), negocio (¿se justifica?), estrategia (¿es lo correcto?) y siguiente nivel (¿movimos al cliente?). Saltar pasos es la causa raíz de la mayoría de los entregables que no firmaríamos.
Voice & ToneComo un consultor senior que también programa.
Específico, calmado, con evidencia. No corporativo, no hype, no cute. La voz no cambia entre cotización, contrato y manual del cliente — lo que cambia es el formato, no la postura.
| Eje | Interna (Slack, runbooks, decks de equipo) | Cliente-facing (cotizaciones, contratos, manuales) |
|---|---|---|
| Pronombre | tú / nosotros | usted por default — bajamos a tú si el cliente lo hace primero |
| Casing | sentence case + abreviaciones técnicas | sentence case, sin abreviaciones |
| Emoji | sí, con criterio | no — excepto markers neutros en plantillas internas |
| Tono | informal pero preciso | formal pero humano |
| Jerga | libre (PR, deploy, SLA, runbook) | inglés solo si no hay buen equivalente; siempre se define la primera vez |
| Largo | breve | breve, con secciones claras y resumen ejecutivo |
Disciplina de redacción. No es preferencia; es contrato.
Hacemos (DOs)
- Decir el costo, el plazo y el riesgo en la primera página.
- Usar números: 12 horas/semana ahorradas, ~14 días hábiles, 35% menos en hosting.
- Empezar oraciones con verbos: "Construimos…", "Recomendamos…", "Identificamos…".
- Cerrar todo correo o documento con un siguiente paso explícito.
- Definir un acrónimo la primera vez que aparece — SLA (Service Level Agreement, acuerdo de nivel de servicio).
- Ser explícitos sobre lo que no hace el alcance — la línea final del scope dice "fuera de alcance: …".
- Diferenciar opinión ("Recomendamos…") de hecho ("El sistema procesa 1,200 facturas/día.").
No hacemos (DON'Ts)
- "Estamos súper emocionados / felices / encantados…" — vacío. Borrar.
- "Lo más rápido posible", "muy pronto", "súper fácil" — impreciso. Usar fechas.
- "Solución integral 360°", "llave en mano", "transformación digital" — corporate slop.
- Franglish-cute: "developear", "releasear", "mergear" → construir, publicar, integrar.
- "Disculpe la molestia" — no nos disculpamos preventivamente.
- Title Case en títulos: Manual Del Usuario → Manual del usuario.
- Exclamaciones en cliente-facing.
- Hipérbole técnica: "el mejor stack del mercado", "la app más rápida".
- Emoji en propuestas, contratos, hoja membretada.
Recomendamos X porque Y.Estructura de toda recomendación
Fuera de alcance: …Línea de cierre de cualquier scope
Riesgo identificado · Mitigación · Owner.Cómo se reporta un riesgo
Lo que entregamos hoy es lo que usaríamos en producción mañana.Cierre de propuesta
La voz, en cinco superficies que escriben los equipos cada semana.
"Hola, ¿cómo estás? Te quería compartir lo que hacemos en DevZen, somos una agencia de software que puede ayudarte con todo lo que necesites. ¿Agendamos una llamada?"
"Buen día, Sr. Reyes. Vimos que Punto Dental abrió tres clínicas en seis meses. A ese ritmo el cuello de botella deja de ser ventas y pasa a ser administración. Construimos sistemas que automatizan agenda, cobranza y reporte clínico para clínicas que escalan. ¿Le agendo 20 minutos esta semana?"
"Vamos avanzando bien con el proyecto, casi está listo, en breve les compartimos."
"Sprint 4 cierra este viernes con: módulo de cotización en producción, integración con SAT en staging (queda regression de 1 día), y dos tickets de UI menores en QA. Riesgo abierto: el endpoint de SAT respondió con timeout intermitente; mitigamos con retry + queue. Sin impacto en fecha."
"¡Listo! Esperamos que disfruten su nueva plataforma. Cualquier cosa nos avisan."
"Sr. Reyes, queda entregada la plataforma. Documentación en /docs, runbook de incidentes en el repo (RUNBOOK.md), y los accesos administrativos en el documento adjunto. La garantía técnica corre 90 días desde hoy; cualquier issue se atiende vía kike@numia.group. Próximo paso recomendado: agendar revisión a 30 días para evaluar adopción y oportunidades de optimización."
Increíbles Resultados
Resultados — Q3 2026
Solicitar mi cotización ahora
Solicitar cotización · Agendar llamada
Vocabulario propioLas palabras importan tanto como el código.
Una marca consistente usa las mismas palabras dos años seguidos. La tabla siguiente es la fuente única para propuestas, decks, web y manuales del cliente.
| Decimos | No decimos | Por qué |
|---|---|---|
| Construimos / desarrollamos / entregamos | Hacemos / armamos | "Construir" implica método. |
| Plataforma · sistema · automatización | Aplicación / app (excepto cuando es móvil) | "Sistema" comunica activo; "app" lo pequeña. |
| Solución | Producto (excepto producto propio) | Vendemos solución; el producto es interno. |
| Software a la medida | Software personalizado / customizado | El término correcto en español de negocios. |
| Ingeniero · equipo de ingeniería | Programador / coder / dev (cliente-facing) | "Dev" es interno; con el cliente, ingeniero. |
| Estrategia técnica | Asesoría tecnológica | "Estrategia" tiene peso; "asesoría" suena timorato. |
| Cotización · propuesta comercial | Quote | En español formal con el cliente. |
| Acta de kickoff | Reunión inicial | "Acta" formaliza; "reunión" desjerarquiza. |
| Sprint · backlog · ticket | Lista de pendientes / tareas | Terminología ágil, ya extendida en LATAM. |
DevZen — no Devzen, no DEVZEN. DZ solo como monograma visual. DevZen Solutions en contratos, facturación y pie legal. Filial de Nümia Group siempre que ayude a contexto — nunca "subsidiaria", nunca "parte de Nümia".
Sr. / Sra. + apellido en primer contacto. "Su equipo", "su operación", "su negocio". Cuando es marca, la marca con artículo si aplica: "trabajamos con Punto Dental", "implementamos para Grupo Reyes".
Si aparecen en un documento que va a salir, hay que reescribir.
Son señal de borrador-sin-revisar. No las usamos en cliente-facing — ni en propuesta, ni en contrato, ni en deck, ni en manual. La excepción única: "llave en mano" en contratos legales si la contraparte lo exige explícitamente.
- Solución integral 360°
- Llave en mano
- Transformación digital
- Sinergia
- Disrupción · disruptivo
- Best in class
- De clase mundial
- Súper / mega / ultra [cualquier cosa]
- Lo más rápido posible
- Estamos emocionados
- Cualquier cosa nos avisa
- Developear · releasear · mergear (cliente)
| Aparece | Reescribir como |
|---|---|
| Lo más rápido posible | Fecha concreta — "viernes 6 de junio". |
| Estamos emocionados de… | Borrar la frase. Empezar por el verbo de acción. |
| Cualquier cosa nos avisa. | Cerrar con siguiente paso explícito. |
| Solución integral 360° | Listar exactamente qué entra y qué no en el alcance. |
| Transformación digital | Decir qué proceso cambia, cómo, y qué métrica se mueve. |
Las palabras prohibidas no son tabú — son señal. Donde aparecen, falta un número, una fecha o una decisión. Regla operativa de redacción
Sistema dual-modeDos superficies. Una identidad. Como un uniforme de fútbol.
DevZen aplica el mismo sistema cromático y tipográfico en dos modos. Tech es el uniforme de local — fondo ink, acentos cyan y morado, gradient permitido. Editorial es el uniforme de visitante — fondo bone, tinta ink, restraint. Mismos hex codes, mismas reglas. Lo que cambia es la superficie y el peso con que se aplica el color.
Dónde vive. Web (devzen.numia.group), pitch deck, social, propuestas digitales, dashboards, mockups en vivo.
Cómo se ve. Surface Ink #0A1128. Tipo blanca y slate. Eyebrows cyan. Una palabra en gradient cyan→morado por pantalla, máximo. Sombras profundas, posible glow sutil en focus.
Por qué. En pantalla, el ink hace contraste con luz emitida — el cyan se percibe vibrante, el gradient lee como dispositivo identitario.
Dónde vive. Hoja membretada, contratos, NDAs, manuales del cliente, casos de estudio impresos, propuestas en PDF para archivar.
Cómo se ve. Surface Bone #F5F2EB. Tinta Ink #0A1128. Stone-200 hairlines. Cyan-deep #058891 reservado a eyebrows, enlaces y border-left de pull-quotes. Sin gradient. Sin sombras dramáticas.
Por qué. El papel no emite luz. El cyan saturado destrumbra; el cyan-deep mantiene el contraste AA sobre bone sin sobreactuar.
La regla maestra: ningún hex code es exclusivo de un modo. Lo que es exclusivo es la jerarquía de aplicación. En Tech, los acentos se permiten en superficie (fondos, fills). En Editorial, los mismos acentos se permiten en filo (líneas, eyebrows, enlaces). Es la misma paleta, dos disciplinas.
El mismo bloque de contenido, renderizado en cada modo.
Una promesa del manifiesto, una nota de soporte y un CTA. Mismo texto, misma jerarquía, misma escala tipográfica. Lo que cambia es la superficie y el peso del color.
Pipelines, generación y QA por default. Criterio humano reservado a diseño de producto, riesgo y trato con el cliente. Ver runbook completo.
Agendar diagnósticoPipelines, generación y QA por default. Criterio humano reservado a diseño de producto, riesgo y trato con el cliente. Ver runbook completo.
Agendar diagnósticoSurface ink (#0A1128). Eyebrow en cyan (#06C4D0). Una palabra — automatizar — recibe el gradient signature (regla: máximo una por pantalla). CTA en fill cyan con texto ink: alto contraste, peso de acción.
Surface bone (#F5F2EB). Tinta ink. Eyebrow en cyan-deep (#058891) para preservar AA sobre bone. Sin gradient. CTA outline en cyan-deep — invitación, no fill.
Two surfaces, one identity. Like a football kit. Concepto operativo · sistema dual-mode
PaletaDoce tokens. Cero ambigüedad.
Toda la marca cabe en doce hex codes. Cada uno tiene un rol específico, un caso de uso, y un caso de nunca-uso. Si un diseño necesita un color que no está en esta tabla, no es DevZen — es otro proyecto.
El gradient cyan → morado. Máximo uno por pantalla.
linear-gradient(90deg, #06C4D0 0%, #8B5CF6 100%)
- Una palabra clave dentro de un hero serif (ej. "tampoco", "automatizar").
- Un CTA hero — máximo uno en la pieza.
- Un badge de eyebrow en posiciones premium (cover de propuesta, hero del sitio).
- Backgrounds completos de pantalla.
- Modo Editorial (membretadas, contratos, NDAs, manuales).
- Detrás del logo (canibaliza la marca-Z).
- Dos veces en la misma pantalla.
Info es un canal distinto del cyan brand — no se confunden. El brand cyan se usa para identidad; el info se usa para estados de UI.
TipografíaUna serif editorial. Una sans neutral. Una mono estructural.
Inter es el default que usa todo el mundo. Söhne es de pago. Geist + Instrument Serif son free, premium, raras en LATAM software — comunican gusto sin costo. La mono está reservada a estructura: eyebrows, meta, números, code.
Once tamaños. Cada uno con un rol.
line 1.04
line 1.08
line 1.18
line 1.18
line 1.18
line 1.18
line 1.18
line 1.55
stone-500
stone-500
tracking 0.18em
Layout, motion, iconografíaEl sistema que sostiene la página.
Grid base 4px. Documentos respiran a 56px de margen exterior mínimo. Web respira a 80px en desktop. Cero fluffy shadows. Cero glassmorphism. Curva única de easing.
Base 4px. Spacing scale: 2, 4, 8, 12, 16, 20, 24, 32, 40, 56, 80, 120. Documentos: 56px outer margin mínimo (letter-size). Web: 80px gutters mínimo en desktop.
UI default 4px. Cards 8px. Hero 16px. Nunca 9999px excepto tag chips.
Hairline 1px stone-200. Focus ring 1.5px cyan.
Sin glow, sin glassmorphism. Las sombras son funcionales — comunican capa, no estilo.
Una sola curva. Cuatro duraciones.
Curva única para todo: hover, page transition, modal, scroll-revealed. Una marca tiene un feel coherente porque sus animaciones aceleran y desaceleran igual.
Duraciones: 120ms (hover, micro) · 200ms (default) · 320ms (page) · 600ms (hero).
Lucide icons — biblioteca MIT, stroke 1.5px, vía CDN. Tamaños canónicos 14 · 16 · 20 · 24 · 32. Color = currentColor — el ícono adopta el color del contexto. Excepción única: logos de stack tech (AWS, Postgres, etc.) mantienen su color de marca.
<script>lucide.createIcons();</script>
- Cero emoji en cliente-facing.
- Cero íconos decorativos. Cada ícono significa algo.
- Si Lucide no lo tiene, no se inventa — se nombra en texto.
- Nunca dos colores en un ícono (excepto logos de stack).
El fondo por default es Bone #F5F2EB en Editorial e Ink #0A1128 en Tech. Nunca #FFFFFF puro en documentos — el blanco puro es display-only (UI elevada, popovers).
Guardrails & Taglines lockedLo que está cerrado. Lo que no se reabre sin Kike Vázquez.
Los dos anchors verbales de DevZen están fijos. Cualquier propuesta de cambio requiere aprobación explícita del CEO. El changelog vive en GOVERNANCE.md.
Reglas de uso: no abreviar — la tensión vive en las dos frases juntas · punto final dentro de la oración (plantilla. y tampoco.) · al romperse a dos líneas, el corte va entre las dos oraciones, nunca a media frase · en Tech, "plantilla" o "tampoco" puede recibir el gradient — una sola palabra, no las dos · en Editorial, sin gradient.
Variantes contextuales permitidas: plataformas → "Construimos dentro de tu negocio, no fuera" · auditorías → "Auditamos dentro de tu negocio, no fuera".
Regla dura: nunca se usa simultáneamente con el master tagline en la misma pieza.
Estas frases viven en cuerpo de copy. No reemplazan los taglines lockeados.
- Calidad Silicon Valley. Sensibilidad LATAM. — descriptor de posicionamiento.
- Software que sube de nivel tu negocio. — audiencia PYME no técnica.
- El negocio que sale de un proyecto con DevZen no es el mismo que entró. — cierre de manifiesto.
Una sola página para imprimir y dejar en el escritorio.
- ·
#FFFFFFpuro como fondo de página - · Gradient cyan→morado en backgrounds completos
- · Gradient detrás del logo
- · Más de un gradient por pantalla
- · Glow, glassmorphism, blur fluffy
- · Paleta jade v2.0 (deprecated)
- · Radii pill (
9999px) fuera de tag chips - · Emoji en cliente-facing
- · Title Case en cualquier encabezado
- · "Solución integral 360°"
- · "Llave en mano"
- · "Transformación digital"
- · "Sinergia"
- · "Disrupción · disruptivo"
- · "Best in class" · "De clase mundial"
- · "Súper / mega / ultra [cualquier cosa]"
- · "Lo más rápido posible"
- · "Estamos emocionados"
- · "Cualquier cosa nos avisa"
- · "Developear · releasear · mergear" (cliente)
- · Exclamaciones cliente-facing
- · Pluralizar el equipo más allá de lo real
- · Sentence case en todos los títulos
- · Pronombre usted en cliente-facing
- · Bone
#F5F2EBcomo fondo Editorial - · Ink
#0A1128como fondo Tech - · Stroke 1.5px en focus rings
- · Hairlines 1px en stone-200
- · Eyebrow Geist Mono 12px / 0.18em
- · Verbos primero en oraciones
- · Números, fechas, owners en propuestas
- · "Recomendamos X porque Y."
En caso de conflicto entre archivos: el colors_and_type.css v2.1 es la fuente operativa. El README.md describe v2.0 jade y quedó huérfano de la actualización — se actualizará por separado. Esta constitución toma como verdad la v2.1.
RatificaciónLo anterior se firma. Lo posterior se enmienda.
Las partes abajo firmantes ratifican el presente documento como el sistema de marca y diseño operativo de DevZen Solutions a partir de la fecha indicada. Toda enmienda futura sigue el procedimiento establecido en GOVERNANCE.md — propuesta escrita, revisión técnica, aprobación de los firmantes, versión incrementada y changelog público.
Tu empresa no es plantilla. Tu software tampoco.
Custodio del manifiesto, voz, taglines y palette v2.1. Toda enmienda al master o campaign tagline requiere su aprobación explícita.
Custodio de la disciplina operativa, vocabulario cliente-facing y aplicación del sistema en piezas comerciales.
- Versión
- v1.0
- Fecha de ratificación
- 22 de mayo de 2026
- Vigencia
- Hasta enmienda formal — sin fecha de caducidad.
- Fuente operativa
colors_and_type.cssv2.1 (manda sobre cualquier conflicto conREADME.mdv2.0)- Enmiendas
- Procedimiento en
GOVERNANCE.md· changelog público en el mismo archivo - Próximo entregable
- Prompt 2 — Design Tokens + Aplicaciones operativas (cotización, hoja membretada extendida, propuesta comercial, email signature, brand kit 1-page)