Productos que puedes entender. Sistemas sobre los que podemos construir.

Qué había que resolver

Un centro médico con un nomenclátor de cientos de servicios tarifados necesitaba que cada servicio fuera una página propia, localizable en la búsqueda, con precio y unidad de medida — no un PDF con la lista de precios. Además, los precios y el equipo cambian, así que la clínica debía poder editarlos por sí sola, y las programaciones debían llegar a recepción de inmediato, no a una bandeja de correo electrónico.

Qué construimos

Next.js 14.2.35 (App Router) con React 18, TypeScript y Tailwind. Cada posición del nomenclátor médico se convirtió en una ruta estática propia: 521 archivos `page.tsx` en `src/app`, de los cuales 481 bajo `/servicii` — 184 fisioterapia, 122 servicios consultivos, 61 exámenes médicos periódicos, 27 ginecología, 26 ozonoterapia, 23 paquetes de tratamiento, 18 medicina alternativa, 12 diagnóstico, el resto por secciones. El sitemap de producción enumera 890 direcciones. El sitio es bilingüe ro/ru. El contenido editable (médicos, paquetes, tratamientos, artículos, ajustes, imágenes) está en una base SQLite local mediante `better-sqlite3`, con journal WAL y claves foráneas activas, administrada desde `/admin` mediante 20 rutas API; la autenticación usa `jose` para la sesión y `bcryptjs` para la contraseña, y el cambio de contraseña invalida las sesiones existentes. Los formularios de programación y de contacto se validan con `zod` + `react-hook-form` y envían el mensaje formateado directamente a Telegram, mediante Bot API. También existe una calculadora de precio en `calculator`.

Qué había que resolver

El menú de un club cambia a menudo, tiene precios y volúmenes que deben ser exactos, y se lee desde el teléfono, en la oscuridad, por personas que hablan tres idiomas. Un PDF escaneado en un código QR no resuelve nada de esto: no se puede buscar, no se traduce, no se actualiza sin volver a imprimir el código.

Qué construimos

Un menú digital sin marco de trabajo y sin paquetes: las fuentes reales son cuatro archivos JSON, y un generador Python de 402 líneas escribe a partir de ellos un único `index.html`. 119 productos en 21 categorías, cada uno con precio, volumen, composición y fotografía; 119 textos breves de presentación, uno por producto; 119 conjuntos de recomendaciones de combinación («con qué va»), que ve el visitante en cada tarjeta. El menú tiene tres idiomas: el rumano es la base, y el ruso y el inglés cubren no solo la interfaz, sino también las categorías, los volúmenes, las composiciones, las 82 etiquetas de sabor y los 119 textos de presentación. El carrito, la lista de favoritos y el reparto de la cuenta funcionan en el navegador, sin cuenta y sin servidor. Las fuentes se alojan en el mismo dominio, no en Google. Antes de cada publicación, un script de 233 líneas ejecuta 16 comprobaciones — que no se haya colado ningún rastreador, que no se requiera nada de un dominio tercero, que el JSON sea válido y que exista cada imagen, que el menú esté completo en los tres idiomas, que los precios bajen en cada categoría y que los datos estructurados de la página sean válidos. La publicación se hace automáticamente desde GitHub Actions al fusionar en `main`, después de que el workflow hace una copia completa de producción y la conserva 30 días.

Qué había que resolver

Una alcaldía de comuna debe tener una página web oficial conforme a la HG 728/2023 — con secciones fijas (transparencia decisional, proyectos y decisiones, anuncios, documentos, contactos, presupuesto) — y debe poder actualizarla por sí misma, sin desarrollador en cada anuncio. Sin esto, la información de interés público queda en papel o en un grupo de Facebook.

Qué construimos

Aplicación Laravel 12 sobre PHP 8.2 con MySQL 8, front-end Vite + Tailwind, empaquetada en dos contenedores Docker (`japca_app` = nginx + PHP-FPM, `japca_db` = MySQL). La arquitectura separa intencionadamente dos tipos de contenido: el editorial que cambia poco (geografía, historia, instituciones, contactos, presupuesto) está en un único archivo de configuración PHP de 1613 líneas que leen directamente las plantillas Blade, y el que cambia a menudo (anuncios, galería de fotos, proyectos y decisiones, documentos, ajustes de transparencia) está en MySQL y se edita desde el panel `/admin`. 40 plantillas Blade, 32 rutas, 10 migraciones de base de datos. La autenticación del panel está limitada a 5 solicitudes por minuto desde la misma dirección — la sexta recibe 429 —, y cada acción de administración entra en una tabla de auditoría. Los encabezados de seguridad y el sitemap están cubiertos por pruebas automáticas que se ejecutan en CI.

Qué había que resolver

Lo mismo que con cualquier menú en código QR: debe ser rápido en el teléfono, correcto en el precio, legible en tres idiomas y cambiable en cinco minutos cuando la cocina saca un plato. Además, el restaurante no necesita ningún tipo de seguimiento de clientes — y entonces la pregunta real es si alguien realmente construye un sitio que no recopila nada, o solo escribe eso en la política de privacidad.

Qué construimos

Un solo `index.html` generado por un script Python de 377 líneas a partir de archivos JSON: 146 productos en 31 categorías, 143 textos cortos de presentación, más las traducciones al ruso y al inglés de categorías, nombres, volúmenes, composiciones, etiquetas y textos. El carrito, la lista de favoritos y el reparto de la cuenta funcionan en el navegador. El sitio se sirve directamente con Caddy 2, con HTTPS automático. Lo interesante es que la no detección del usuario no es una promesa, sino una regla impuesta por la integración continua: en cada solicitud de fusión, CI regenera `index.html` a partir de las fuentes y rechaza el PR si el resultado difiere del archivo del repo (por lo tanto, la página publicada siempre coincide con las fuentes), luego ejecuta 14 verificaciones —sin rastreadores, sin ningún recurso cargado automáticamente desde un dominio tercero, fuentes alojadas localmente, sin archivos de copia de seguridad llegados al repo, política de privacidad presente y enlazada desde el pie de página, menú completo en tres idiomas, precios en orden descendente en cada categoría, datos estructurados válidos— y verifica incluso que de la configuración del servidor no hayan desaparecido las cabeceras de seguridad y el ocultamiento de la dirección IP en los registros. Todas las acciones de GitHub usadas están fijadas al hash del commit, y el workflow se inicia con `permissions: {}`.

Qué había que resolver

sin verificar — no tenemos las fuentes, así que no puedo describir el problema de trabajo sin inventarlo.

Qué construimos

Aplicación React compilada con Vite, servida estáticamente por nginx, con versión en ruso en `/ru/`. 181 direcciones en el sitemap de producción. Eso es todo lo que se puede afirmar desde fuera: las fuentes no están en esta máquina, así que no puedo nombrar las bibliotecas, la estructura ni las integraciones.

Qué había que resolver

Un centro estomatológico distrital necesitaba una lista pública de servicios con precios, marcado claro de los cubiertos por el seguro obligatorio, equipo, horario de urgencias y páginas de transparencia, editables por el personal, no por un programador. Cuando tomé el proyecto, el panel de administración tenía un problema grave: la contraseña de admin se comparaba en el navegador y llegaba al paquete JavaScript público, y las solicitudes de escritura en la API podían hacerlas cualquiera en internet.

Qué construimos

Aplicación React 18 + TypeScript en Vite 6, con enrutado `react-router-dom` — 22 pantallas, desde servicios y precios hasta urgencias, ortodoncia, implantes, pedodoncia, transparencia y feedback. En la parte de atrás, una API Express 4 arrancada bajo PM2; nginx sirve los archivos construidos y solo reenvía `/api`. Los datos públicos (servicios, equipo) están en archivos JSON leídos tanto por la API como directamente por el front-end. La parte que aportamos nosotros es la seguridad: la contraseña ya no sale del servidor — `POST `login` la verifica allí y devuelve un token firmado HMAC-SHA256 válido durante 12 horas, con límite de 8 intentos por 15 minutos por dirección IP y comparaciones en tiempo constante; las escrituras en `services` y `team` ahora exigen el token; el secreto de firma se genera solo en un archivo con permisos 0600, guardado fuera del repo; la API escucha solo en 127.0.0.1, así que nginx es la única vía pública; CORS está limitado a los dominios propios, y el cuerpo JSON está limitado a 1 MB. Encima de eso pusimos CI que compila, verifica los tipos y rechaza el paquete si encuentra un secreto en él, más Dependabot con ritmo semanal para npm.

Qué había que resolver

Una empresa de crédito necesita más que un sitio: la solicitud debe entrar online, pasar por un flujo de decisión, generar un contrato PDF, crear un calendario de pagos y dejar rastro en auditoría — y todo debe resistir las preguntas que hace un cliente que pide de vuelta sus datos personales. La parte pública (calculadoras, artículos, páginas por tipo de crédito) debe al mismo tiempo atraer gente desde la búsqueda.

Qué construimos

Dos mitades en el mismo depósito. La parte pública es una aplicación Vite + React Router compilada estáticamente — 50 pantallas, entre ellas cuatro calculadoras (crédito, elegibilidad, refinanciación, calendario de pagos), páginas separadas por tipo de crédito, blog, páginas de información precontractual y de conformidad. Las rutas rumanas quedan sin prefijo, y las rusas van por `/ru/…`, con etiquetas canónicas y alternativas generadas a partir del idioma de la ruta activa. La parte de negocio es un backend Express modular en TypeScript, con Prisma sobre PostgreSQL: 16 módulos — autenticación, derechos por rol, flujo de solicitudes, documentos, pagos, notificaciones, tareas programadas, blog, SEO, GDPR, clientes, leads, contacto, calculadora, Google Ads, salud — y 18 tablas en el esquema Prisma, entre ellas `Contract`, `Payment`, `AuditLog`, `GdprRequest`, `UploadedDocument`, `DailyKpiSnapshot` y `CronJobRun`. Funciona bajo PM2, con scripts separados para migraciones en producción, verificaciones antes del lanzamiento, generación de secretos, copia de seguridad y restauración de la base.

Qué había que resolver

Un servicio auto se busca en combinaciones muy específicas — marca más operación más barrio („reparación caja automática BMW Botanica”). Una sola página „Servicios” no puede responder a nada de eso. El problema técnico es que el sitio es una aplicación React de una sola página, así que lo que ve el motor de búsqueda es un `<div>` vacío si no se hace algo específico.

Qué construimos

Aplicación React 19 + TypeScript sobre Vite 6, con React Router, pero prerenderizada en compilación: cada ruta sale del build como un archivo HTML propio, así que el motor de búsqueda recibe contenido, no una página vacía. La estructura de direcciones se amplió en etapas verificables en el historial — de 206 páginas indexables, a 316 mediante la adición de las combinaciones marca × categoría de trabajo, los artículos y las páginas por sector de Chisináu. Las rutas tienen versiones por idioma, un sitemap de imágenes separado, imágenes Open Graph y el paquete JavaScript dividido para una carga más rápida. El último commit corrigió un detalle que rompe la indexación en silencio: la dirección canónica, el `hreflang` y las direcciones del sitemap emiten ahora todos la misma forma con barra final.