Cómo trabajamos

Esta página cubre dos cosas. La primera es qué pasa cuando decides trabajar con nosotros: los días, las semanas, qué ves y cuándo. La segunda es cómo está construido el sitio que estás leyendo — porque no tenemos una demo que enseñarte, tenemos esto.

Días 1 a 3: el diagnóstico

Antes de escribir una línea de código hay que entender cómo opera tu negocio hoy. No cómo debería operar. Cómo opera.

Son un par de conversaciones. Quién hace qué, en qué momento del día se atora todo, qué se sigue llevando en papel o en un chat, qué software ya pagas y para qué lo usas de verdad. Tú ya tienes la respuesta adentro; lo que falta es alguien preguntando en el orden correcto.

De ahí sale el alcance exacto y un precio cerrado. No una tabla genérica.

Y sale otra cosa que a nadie le conviene decir: si tu problema no se resuelve con software, te lo decimos ahí mismo. A veces lo que falta es una persona. A veces el precio está mal puesto. Venderte un sistema para eso sería cobrarte por no resolverte nada.

El diagnóstico no se cobra y no te obliga a nada.

Semanas 1 a 6: construcción en sprints

Cada semana cierra con una demo en vivo. No un reporte, no capturas de pantalla: el sistema corriendo, en tus manos, y tú diciendo qué está bien y qué no.

Esto no es cortesía, es lo que evita el desastre clásico. Si en la semana 2 ves que la pantalla de pedidos no funciona como la imaginabas, se corrige en la semana 3 y cuesta unas horas. En el modelo de "te entrego en tres meses", ese mismo error aparece al final, cuando corregirlo significa rehacer.

El orden también importa: lo primero que se construye es lo que hoy te está costando dinero. Lo bonito viene después.

El repositorio vive en tu cuenta desde el día 1, no se te transfiere al final.

Semanas 4 a 8: lanzamiento

Despliegue, pruebas y traspaso completo: los accesos a tu nombre, el dominio tuyo, los datos tuyos y la documentación de cómo está armado todo.

El rango se traslapa a propósito con el anterior. Un sistema chico se lanza en la semana 4; uno con más piezas —usuarios, permisos, cobros, integraciones— en la 8.

Y el lanzamiento no es el día que el sistema sube a internet: es el día que alguien de tu equipo lo usa en su jornada normal y funciona. Hasta ahí te acompañamos.

Lo que se pregunta antes de decir que sí

¿Cuánto cuesta?

Depende de dos cosas fáciles de explicar: cuánta gente lo va a usar y cuánto tiene que hacer solo, sin que tú intervengas. No cuesta lo mismo un sitio donde tú cambias fotos y precios que un sistema con usuarios, permisos, cobros y reglas de negocio propias. El número sale del diagnóstico, cerrado antes de empezar. Si a mitad del camino aparece algo que nadie había considerado, se cotiza aparte y tú decides si entra — no te llega una factura sorpresa al final.

¿Quién le da mantenimiento después?

La mayor parte no depende de nosotros, y eso es a propósito: el contenido lo mueves tú desde tu panel, y lo de abajo —servidor, base de datos— corre sobre servicios que se actualizan solos. Hay soporte incluido después del lanzamiento; si quieres algo continuo más allá de eso, se acuerda por escrito, con lo que cubre y lo que no.

¿Yo voy a poder cambiar cosas, o cada vez tengo que hablarte?

Si en tu negocio el contenido se mueve seguido —precios, fotos, disponibilidad, horarios— el sistema se entrega con su propio panel: entras, lo cambias, se publica en minutos, sin saber nada de programación. Y si tu caso es de los que casi no se mueven, te lo decimos y no te cobramos un panel que no vas a abrir: cobrar por una función que nadie usará es la forma más fácil de inflar un presupuesto.

¿De quién es el código?

Tuyo, desde el día 1. El repositorio —donde vive el código de tu sistema— se crea en tu cuenta al empezar, no se te transfiere al terminar. Sin dependencias ocultas y sin candados que te aten a nosotros.

¿Mi equipo lo va a saber usar?

Se diseña pensando en quien lo va a usar en el turno de las siete de la mañana, con las manos ocupadas, no en quien lo programó: pantallas simples, pocos pasos, sin claves de más que memorizar. Y antes de que decidas, te mostramos en vivo un sistema real ya operando para que lo juzgues tú, no para que nos creas.

¿Qué pasa si un día dejamos de hablarnos?

Es la pregunta que más pena da hacer y la más justa. La respuesta es que no se apaga nada: tu información vive en tu propia instalación —tu dominio, tus datos, tu repositorio— no en una plataforma nuestra que te la pueda quitar. Si mañana quieres seguir con otro equipo, todo está documentado y es tuyo. A nombre de quién queda cada cosa se deja por escrito antes de empezar, no después.

Cómo se hizo este sitio

El lema de la casa es que no vendemos demos. Así que la demo es esto: el sitio que estás leyendo, con el mismo stack y criterio con el que se construye lo tuyo.

El stack, y por qué

Next.js 16 con React 19 y TypeScript, estilos con Tailwind, datos y autenticación en Supabase, desplegado en Vercel. Traducido:

• Next.js arma la página en el servidor antes de que llegue a tu teléfono: el texto se ve de inmediato, sin esperar a que se descargue un programa que lo dibuje.
• TypeScript le pone reglas al código, así un error se detecta al escribirlo y no cuando un cliente lo encuentra.
• Supabase es donde viven los datos, con los permisos aplicados en la base misma y no solo en la pantalla. La diferencia importa: una pantalla se puede rodear, la base no.
• Vercel publica cada cambio en minutos y permite regresar a la versión anterior si algo sale mal.

Es el mismo stack de los sistemas que ya operan. No estrenamos tecnología con el proyecto de un cliente.

Todo el movimiento está hecho en código. No hay un solo video.

Nada de lo que se mueve aquí es un video. Es todo cálculo:

• El scroll suave con inercia lo maneja Lenis, con un solo reloj compartido para que nada se desfase.
• Los títulos se revelan línea por línea: el texto se parte en líneas reales, ya con la tipografía cargada, y cada una sube desde detrás de una cortina.
• Las tarjetas aparecen con un barrido de abajo hacia arriba, todas con el mismo ritmo, para que el sitio se sienta como una sola mano.
• Los botones persiguen un poco al cursor y regresan con inercia.

Y el fondo del inicio son 30,000 partículas dibujadas por la tarjeta gráfica: treinta mil puntos cuya posición se recalcula desde cero, decenas de veces por segundo, con dos fórmulas. Una onda lenta que hace respirar al campo entero, y otra que nace donde está tu cursor y se apaga con la distancia. Por eso el fondo reacciona a ti — un video no puede hacer eso. Y pesa lo que pesan las fórmulas, no lo que pesaría el video.

Ese criterio se aplica hasta en lo chico. Los botones magnéticos iban a hacerse con una librería popular; medido en nuestro propio build, metía 148 KB extra a la primera carga para animar tres botones. Se hicieron con la que ya estaba adentro: mismo efecto, 148 KB menos.

Todo eso se apaga solo, y por eso importa

Hay dos interruptores, y ninguno lo mueve el visitante.

El primero es la preferencia de "reducir movimiento". Cualquier persona puede activarla en su sistema operativo, y quien la tiene puesta suele tenerla porque el movimiento en pantalla le provoca mareo, náusea o dolor de cabeza — no es una preferencia estética. El criterio 2.3.3 de las WCAG pide justamente eso: que la animación disparada por la interacción se pueda desactivar, salvo que sea esencial.

Cuando ese interruptor está activo, este sitio no anima nada. Y no es que anime menos: el scroll suave se desmonta por completo y vuelve el scroll normal del navegador, los títulos aparecen sin cortina, y las partículas ni se cargan.

El segundo es el teléfono. En móvil, la librería 3D del fondo ni siquiera se solicita. Pesa cientos de kilobytes, y descargarla con datos móviles para pintar un adorno es cobrarle al visitante por decoración.

Esto no es delicadeza, es velocidad. Google mide cuánto tarda en aparecer el contenido principal de una página; según web.dev, se considera buena si eso ocurre en 2.5 segundos o menos, medido en el percentil 75 de las visitas. Aquí el contenido principal es el titular, y se manda ya armado desde el servidor. Las partículas llegan después, si es que llegan. Un sitio que tarda es un sitio que la gente cierra antes de leerte.

Cómo se usa la IA aquí

La IA es la herramienta con la que se construye. No es el producto que se vende.

Se usa todos los días para leer un código base completo, proponer, escribir y revisar lo escrito. Por eso un proyecto sale en semanas y no en meses. Pero lo que se te entrega no es "un modelo": es un sistema con su base de datos, sus permisos y tus reglas de negocio adentro.

La distinción te conviene a ti. Si mañana sale un modelo mejor o más barato, tu sistema no se rehace — se cambia una pieza. Compraste el sistema, no el modelo.

Y cuando la IA sí es parte del producto —como el que atiende WhatsApp y agenda citas, o el que escribe guiones de video— se dice con claridad qué hace y qué no. Nunca "IA" como adorno en una lista de características.

Una última cosa que también se entrega: los archivos de este sitio llevan comentarios que explican por qué se tomó cada decisión, no solo qué hace el código. Si otro equipo lo toma mañana, entiende el porqué.

El siguiente paso es el diagnóstico

Es gratis y no obliga a nada. Son unas preguntas sobre cómo opera tu negocio hoy: dónde se atora, qué se sigue haciendo a mano, qué se te está yendo sin que lo veas.

De ahí sale el alcance y el precio. O sale que no necesitas software, y también te lo decimos.

Te contesta Ivan, no un vendedor.